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ABSTRACT 


This thesis examines the design and development of a desktop prototype of a 
computer wargame. The prototype specifically deals with the ability to format the 
Joint Theater-Level Simulation’s Model Interface Program (MIP) into the visual 
interface format of computer graphics known as window nianagement. In this case, 
the Apple Macintosh microcomputer, a desktop computer, was used as the operating 
system for implementation of this prototvpe. The development of the prototype is 
examined with respect to the current version of the MIP. The prototype development 
is based on software design applications which include design models, correlation of 
programming languages to operating systems, and a breakdown of the design into a 
modular format. The thesis concludes with recommendations for changes which can 


enhance the use of the prototype from both a technical and managerial standpoint. 


THESIS DISCLAIMER 


The reader is cautioned that computer programs developed in this research may 
not have been exercised for all cases of interest. While every effort has been made, 
within the time available, to ensure that the programs are free of computational and 
logic errors, they cannot be considered validated. Any application of these programs 


without additional verification is at the risk of the user. 
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I. INTRODUCTION 


Pee PURPOSE OF THESIS 

The purpose of this thesis is to examine enhancements of the human interface to 
an interactive computer simulation program by applying computer graphics techniques 
to the interface. These graphics techniques are known as the visual interface and have 
found widespread applications in man-machine interaction. In this study the viability 
of applying such an enhanced interface to an existing application is based upon three 
factors: 1) The casual user of such an application does not have or maintain the 
necessary skills to efficiently utilize the application. 2) The technology which supports 
the enhanced interface has advanced past the technology of the current application's 
design since the design was frozen and implementation of the design into a finished: 
product was begun. 3) The low cost of computer's with large amounts of memory and 
extremely capable CPUs has led to a proliferation of advanced microcomputers. Given 
these factors, the development of an enhanced interface is achieveable. 

The achievement of the enhanced interface requires a knowledge of background 
information about the interface subject. The subject is the Joint Theater-Level 
Simulation (JTLS) and it’s user interface. By beginning with the purpose of JTLS and 
how it is utilized, the scope and organization of the research of this thesis may be 
established. The background information about JTLS and the scope of the research 
follow later in this section. Chapter 2 examines the current JTLS interface (the Model 
Interface Program), it’s design and structure, it’s current functions, and it’s modus 
operandi. Chapter 3 discusses the design of an enhanced interface, the correlation of 
the current interface with the enhanced version, the enhanced versions modus operandi, 
concludes with proposals and observations about various aspects of the enhanced 
interface development and utilization. Chapter 4 concludes the thesis with a 
Summarization of the enhanced interface prototype design and it’s usage. These 
sections flow from the basic design and operation to an enhanced design and purported 
operation which is achieveable. The research begins with the background review of 
JTLS. 


B. BACKGROUND 

The goals and scope of this thesis are predicated upon understanding the object 
examined. The nature of the object, it’s reason for being to include a brief review of 
it’s history, and it’s present technical configuration provide a basic foundation upon 
which this research may be built. The object is JILS and it’s nature is that it is an 
interactive computer siinulation model used for warganung. The original objectives 
behind the design of JTLS and how those objectives have evolved are discussed to 
provide a link to future JTLS use. Finally, the present technical configuration of JTLS 
presents it’s hardware and software elements which are the backbone of JTLS 
implementation. A more detailed discussion of these elements follow. 

Computer simulation is an effective, economical method of analvzing mulitary 
plans and operations without actually employing the mulitary forces which carry out 
those plans and operations. It is possible, using computer-based simulation, to ‘trace, 
in detail, the consequences and implications of a proposed course of action [Ref. I: p. 
1-2]. One such simulation (or wargame) is the Joint Theater Level Simulation (J THES 

A complete set of manuals documenting JITLS, from it’s inception to it’s 
unplementation, has been published. Much of the following background information ts 
taken from the JTLS Executive Overview manual. JTLS is a computer-assisted 
Wargaming svstem that models two-sided air, ground, and naval combat. It was 
designed for use in warfare training, joint operational planning, and doctrinal analvsis 
with an emphasis on rapid production of results, theater-independence, and ease of use 
for non-progranimers. The original design objectives of JILS were to 1) provide a 
contingency planning analysis tool for the United States Readiness Command, 2) 
provide an educational wargame and analytic capability for the United States Army 
War College, and 3) provide an analytic tool aiding contingency plan evaluation for the 
United States Armv Concepts Analysis Agency. 

In 1985, the Joint Analysis Directorate of the Organization of the Joint Chiefs of 
Staff assumied responsibility for the control and direction of future JTLS development 
efforts. (The Joint Analysis Directorate is now the Force Structure, Resource, and 
Assessment Directorate (OJCS/J8). This was done as part of a program to upgrade 
the analytic tools available to the unified Commanders in Chicf for use in war 
planning. Included in their interests are future developments of JTLS which enhance 


user friendliness through advanced technologies such as the visual interface of window 
management. 
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The need for enhancements to the human interface are due to the nature of the 
use of JTLS. As an analytic tool it is used sporadically to test doctrine, strategies, and 
tactics by a variety of users. Frequently, these users are not computer operators by 
trade nor do they spend many hours playing JTLS. Their primary interest in JTLS 1s 
the outcome based upon a preformatted and staged input to the game. They do not 
need a complicated, difficult to learn ( and easy to forget) computer simulation that is 
not readily usable when they are trying to develop and conduct an experiment with 
warplans. The Model Interface Program (MIP) can be such a program for the casual 
user. Unless the user frequently plavs JTLS, the operation of the MIP is moderately 
difficult on which to maintain proficiency and it is not conducive to quickly 
resurrecting lost proficiency. 

The JTLS svstem is designed to operate on Digital Equipment Corporation’s 
VAX muinicomputer systems, including the 11/780, 11/785, and 8600 computers. The 
minimum hardware configuration for JTLS consists of four video terminals and one 
on-line printer. The maximum configuration consists of 28 video terminals, 10 graphics 
displays, and one or more line printers. 

The following support software 1s required to implement JTLS: 

1) A VAX/VMS operating svstem. 

2) ASIMSCRIPT II-5 programming language compiler. 
3) AC” programming language compiler. 

4) An INGRES data base system. 

Most of JTLS is written in the computer language SIMSCRIPT II.5 (a registered 
trademark of CACI, Inc.). The language is designed to facilitate the simulation of 
large, complex systems. The simulation constructs are embedded in the language, 
which is free-form and English-like. SIMSCRIPT II.5® also has such automated 
features as statistics-gathering mechanisms, dynanuc storage management, and flexible 
report generating. For these reasons and others, SIMSCRIPT I1.5® was selected as 
the high level programming language for the simulation applications. [Ref. 2] 

JTLS may be summarized as being a complex, sophisticated set of computer 
programs which may have more extensive capabilities when properly configured and 
used. With these facts about JITLS in mund, the exanunation of the plaver interface to 
the JTLS may be conducted. 


iL, 


C.. SCORE 

The Joint Theater-Level Simulation (JTLS) is an interactive computer simulation 
model used for wargaming of theater conflicts. The nature of a two-sided computer 
simulation, such as JTLS, is to produce an outcome as the result of the interaction 
between the two opposing sides. In this case, the two sides simulate combat by 
directing simulated military forces into proximity, with the result being an outcome of 
a battle. The whole impetus behind this simulation is the involvement of the plaver, 
i.e., the human interface. The main area of interest in this study is the Model Interface 
Program (MIP). It is through this program that the human interaction with the game 
is conducted and is what the prototype design will enhance. 

Several avenues of research may be taken to develop the aforementioned 
prototype. The method used here is to develop the prototype using as much of the 
existing MIP source code as possible. This approach provides an economical, quick 
ability to implement a full-scale visual interface. The efficiency of such a prototype 
compared to a total redesign of the MIP in terms of future expansions or computer use 
will not be addressed in depth. 

The general operation of a JTLS simulation is to conduct an interaction within 
the combat simulation bv issuing orders to the available nulitary forces. The Combat 
Events Program (CEP) compares the actions of the forces, within the limitations of 
their environments, and vields the results of the combat. As a result of the interaction, 
the conimanders of the forces must continuallv make decisions during the course of the 
game. These decisions (the issuance of orders) are transmitted to the CEP via the 
Model Interface Program (MIP). Thus, the MIP is an interactive program used by all 
players. 

The present version of the MIP, while fullv capable of interacting with the CEP, 
is considered unwieldy for the occasional user, difficult to learn, and slow in terms of 
conducting a fast paced simulation. Of primary concern is the methodology of issuing 
orders to the CEP. While this methodology is examined in depth later in this thesis, it 
mav be safely stated that the MIP lacks user friendliness for the occasional user and is 
not meeting current and future requirements for the purposes of player interaction with 
the game. 

One method of enhancing plaver interaction to JTLS is the use of the visual 
interface. The visual interface was borne out of the “need for creating easv-to-learn 


and easy-to-use applications” [Ref. 3]. Some advantages of the visual interface are to 


increase the data absorption rate by the user, reduce input/output errors such as those 
which occur during the typing of data, provide the user a “positive transfer of learning” 
to the new system, and the reduction of user anxiety caused bv a lack of control or a 
lack of information [Refs. 4,5]. The visual interface simply allows the user to “see” 
what is going on; a much faster process than “reading” what is going on. 

Implementing the visual interface is done through a variety of computer graphics 
applications. The visual interface application examined in this thesis is that of window 
management. Window management deals specifically with the methods of creating 
graphical forms (windows), and displaying’manipulating information within those 
windows. The Apple Macintosh™ is an excellent machine for implementing the use of 
window management techniques in microcomputer application programs. 

The scope of this thesis will be to investigate the current methodology of creating 
a player order (a directive) and issuing it to the Combat Events Program(CEP), 
breaking down the methodology to create and issue the order, and reconstructing the 
methodology using the visual interface format. The particular case study will create an 
air directive, with it’s associated utility directives, and send it to the game. In doing so, 
much of the material to follow will examine particular commands and directives as 
representative functions of the overall MIP. The methodology developed and used in 
the course of designing the prototype will be a useful tool in the expansion of the 
prototype to include all MIP functions in a Macintosh interface. In the opinion of the 
author, the basic constructs of the visual interface prototype should also be useful in 
the event of a total redesign of the MIP. The study begins with a detailed examination 


of the current Model Interface Program. 
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Il. THE MODEL INTERFACE PROGRAM 


A. THE RELATIONSHIP BETWEEN JTLS PROGRAMS 

The JTLS Executive Overview addresses the overall structure of JTLS. The 
JTLS system consist of several independent programs which work together as a system 
of functions. The functional programs of JTLS are described below. The functional 
programs of JTLS have a variety of interrelationships as shown in Figure 2.1. It is 
through these relationships that the MIP initializes itself; obtains data from databases, 
files, records, and displays; and performs its functions. 

The functions of the Model Interface Program are: 

1) Entering orders. 
2) Processing orders. 
3) Communication between players and game controllers. 
4) Communication between the players and the combat simulation. 
5) Accessing and using support information. 
6) Saving directives in archive files. 
7) Analyzing post-processor data. 
8) Controlling graphics output. 
9) Stopping or temporarily halting the game. 

To accomplish any of these functions the MIP must depend on the other JTLS 
programs for support. For example, the CEP and Executive Program provide the 
information required by the MIP to create and process orders. The game’s scenario 
database, which provides the players units, equipment, etc., is created by the Scenario 
Preparation Program. While the MIP does not communicate directly to all JTLS 
programs, it does have an indirect relationship to those outlying programs. In concept. 
since the MIP is a critical function of the execution phase of JTLS, its importance 


demands the support of the other programs and, in turn, results in the relationships 
shown. [Ref. 2] 


B. THE MIP STRUCTURE 

The structure of the MIP can be derived from its functions, its relationships, and 
the high level language SIMSCRIPT II.5® used to program the MIP. In deriving the 
structure, several system models were developed to express the why, what and how of 
the MIP. These models are discussed below. 
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1. The Fundamental Nlodel 
The overall system model is the fundamental model, Figure 2.2. In this model 
the various user inputs to the program are shown as well as the outputs of the 
program. Note that the functions are not delineated here since they are inherent to the 
MIP in this model form. The purpose of the fundamental model is to define the 
desired results and identify the necessary inputs while leaving the identification of 
specific contributors to any given function to the program. The “how” is examined in 


greater detail through data flow diagrams. 


INPUTS ("Keyboard } OUTPUTS 


Player Function 


Directive Types Player Orders 


Directive Attributes MODEL 
INTERFACE Messages 


Commands PROGRAM 


Messages a Reports 


Queries 





Figure 2.2. The Fundamental Model. 


2. The Data Flow Diagram 

The data flow diagram, Figure 2.3, displays the flow of information from the 
plaver to the game. Although not intricately detailed here, it does show the basic 
transformations which take place, what type of information is passed, and the location 
of sources or sinks of information. 

A significant portion of the Mow of information from the player (the input) to 
the game (the output) deals with the directive. The directive is the heart of the game in 
that it hterally causes an interaction to take place in the game thus producing some 
outcome. Without the directive, there would be no simulation model. Due to the 
directive’s importance to this application, much of the design is described with the 


directive as it’s focat point. To appreciate the directive’s impact on the flow of 
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Figure 2.3. The Data Flow Diagram of the MIP. 


information, one must understand that most of the data is manipulated with the goal 
of developing and exercising a directive. 

At this point it 1s necessary to understand the performance of the various 
elements of the data flow diagram. In the case of the player creating an order, the 
player first enters a command. The transformation of the input is the performance of 
that command. If the conmand was a create command then the next transformation 
would build the directive using the attributes entered by the plaver. When all the 
attributes have been entered, the player enters another command to tell the MIP the 
directive is completed and to manipulate the directive. For example, this could be a 
verify, hold, save, or send conmmand. Any conunand other than a send command would 
require the player to enter more commands before the directive could be sent to the 
CEP. When the player issues a send command, the directive is formatted into an order 
message the CEP can read and understand. The order message is then placed in the 
CEP’s mailbox. 

A key issue here is that the player is constantly entering data directly into 
transformation modules without the data flowing in a “fluid” manner towards an 
Output. The superimposed box outlines a bottleneck of data flow in the data flow 


diagram. This bottleneck places a great demand on the player to provide data in this 
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model. The source of the player’s data is a computer printout of function specific 
information printed prior to plaving the game. This 1s undesirable since all (or nearly 
all) of the data necessary for transformation during the creation of a directive is 
available in a database or file in the game itself. In particular, a file called the Player 
Initialization File (PIF) exists for each player and contains much of the information 
needed by that player to perform transformations, 1.e., developing directives. Ideally, 
the transformation mechanism , vice the player, would do the work of sourcing and 
entering the data. Such a mechanism can be created using the graphics interface 
environment. 
3. The Data Structure 

The data structure of the MIP is a hierarchical system that is implemented by 
using multi-linked lists containing scalar items, vectors, and n-dimensional spaces. In 
SIMSCRIPT these concepts are established first as entities. These entities are 
characterized by their attributes. If there are logical associations or groupings of 
entities, they are described asi sets, {Rel lo somme | 

A set is a logically ordered collection of entities organized through a system of 
set pointers. A pointer is the address in memory of a data item. For examplemane 
MIP has a set of targets with pointers to (1.e. the addresses of) the first and last 
members of the set and the number of members (targets) in the set. Figure 2.4. These 
attributes of the set are considered to be owner attributes. Each member (target) has 
pointers to (addresses of) the preceding and succeeding members of the set as well as a 
flag to record membership in a set (to disallow multiple membership). 

Entities may be permanent or temporary. The permanent entities exist 
throughout the simulation unless they are explicitly destroved. Temporary entities are 
those which are short-lived during the simulation or for which the number of copies 
varies within the execution of the simulation. 

Figure 2.5 shows an example of some permanent and temporary entities. While 
AIRCRAFT _(1) and AIRCRAFT (2) exist in storage throughout the game. the 
RECOGNIZED_COMMAND is only put into storage at the time it is created. 

All of the data used in the game by the MIP is stored in these sets, entities, or 
attributes. Their definitions may be found in the MIP’s source code preamble. All of 
the data needed to create plaver directives is found in these data structures (primarily in 
the PIF). However, the data structures aren’t effectively used. This was demonstrated 


In an earlier section and will be discussed later in this thesis. For example, the 
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Figure 2.4 An Example of Sect Organization. 
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Figure 2.5 Examples of Entities. 


AWACS air directive only uses data from the permanent and temporary entities hsted 
in Figure 2.6. The PIF’s function here is simply error checking to ensure the data 
entered 1s correct with respect to the scenario’s data. The poor use of the PIF results 


in the increased burden of furnishing data being placed upon the user. 
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Figure 2.6 The AWACS Directive Data Structure. 


C. THE MIP FUNCTIONS EXAMINED IN THIS PROTOTYPE 


1. The Commands 


The MIP has 36 commands which perform environmental, directive specific, 


Or group of directives specific tasks for the player. These commands essentially 


instruct the MIP to take further actions which have been defined bv the player to 


accomplish his decisions. The environmental conimands perform the adnunistrative 


tasks such as printing, spooling, scanning, finding, etc. The other two categories of 


commands manipulate the directive(s) by creating, changing, sending, etc. At times, 


the delineation of these commands into the three categories seems vague. I[lowever, 


this delineation will become clear later when the visual interface is applied to the MIP 


functions. 


The specific commands of interest and their definitions are as follows: 


© CREATE 
© GCREATE 


° QUERY 


e FIND 


SCOry 


The create conumand allows the player to create a directive within 
the domain of the player’s function. 


The gcreate command allows the player to create a group of 
directives within the domain of the plaver’s function. 


The query command allows the ree to request that the CI:P send 
ns plaver standardized reports Which pertain to the player's 
UNCON. 


The find command allows the player to hold a directive that was 
previously in existence. 


The copy command allows the plaver to create a directive whose 
attributes, except for the identifier, are identical to those of an 
existing directive of the same type. 
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¢e GCOPY 


¢ JOIN 


SPE AVE 


¢e GCLEAR 


* DISPLAY 


SGUISPLAY 


eo MENU 


e SAVE 


e LOAD 


¢e TRANSMIT 


e SCAN 


Sor OOL 


Se RINT 


sexe PRESH 
° SET 


¢e ADJUST 


ice LL RN 


* SEND 


The gcopy command allows the player to create a group whose 
attributes, except for the identifier, are identical to those of an 
existing group. 


The join command allows the player to place a directive into a 
group. 


The /eave command allows the player to remove a directive from a 
group. 


The gclear command allows the player to empty a group of all it’s 
directives. 


The display command allows the player to see which directives of a 
articular tvpe have been created in the past and still exist. 1.e., 
ave not been deleted. 


The gaisplay command allows the player to see which directives are 
in a particular group 


The menu command allows the plaver to view the menu of any 
existing directive without holding onto it. 


The save command records all of the players undeleted directives 
onto a file called the Archive File. 


The load command 1s used to bring directives from an Archive File 
into the MIP 


ie transmit command is used to transmit messages to other 
players. 


The scan command allows the player to view several messages in 
succession. , 


The spool command allows the plaver to put several messages in his 
or. her print file without taking the time to examine them. 


he ig command prints out a hard copy of all messages filed or 
spooled. 


The refresh command brings up a fresh MIP screen. 


The set command allows the plaver to set various parameters that 
tailor the use of the MIP to the player’s liking. 


The adjust command allows the plaver to adjust the display of his 
graphics station. 


The return command is used in conjuction with the exclamation 
mark to allow the plaver to use the OVERAIIP feature. The return 
command conveys the player's intent to abandon the current 
overmip and résume action that. the. plaver had_ previously 
interrupted with the most recent exclamation mark. (NOTE: The 
OVERMIP feature freezes the current plaver action allowing the 
plaver to perform some other action and then return to the point 
Where the frozen action was interrupted. Not all player functions 
can be performed in the OVEARAIIP feature.) 


The send conimand_ts used to send_the information contained in a 
directive to the CEP in the form of a player order. The command 
onlv applies to, the held directive. if there is one. (NOTE: The send 
conmimand applies onlv to action directives. CLtilitv directives cannot 
PeccHi i emtlew@miemexPHCiLiviardtmer, the iniormation contained in 
them is sent as part of the action directives that refer to them.) 
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© GSEND The gsend command is used to send, one at a time, all of the 
directives belonging to a particular group. 


¢ CHANGE _ The change command is used to change specific attributes of the 
held directive after its initial creation. 


* RESTORE’ The restore command allows the plaver. to override all change 
conimands performed in the held directive since it was last held. 


°e PAGE The a conimand lists the menu of the held directive and, if the 
directive menu is contained on more than one page, it will cause the 
MIP to enter the paging mode. 

* VBRIPY The ey command performs all validation checks not performed 
during the creation of a directive or the changing.of attributes. 


©GVERIFY The gverify command performs the verify command for each 
directive in a particular group. 


* DEER RE He Cee command permanently removes the held directive from 
ice 4 


¢GDELETE The gdelete command permanently eliminates a group of directives 
irom thes vine 


® DONE The done command returns the MIP to a state in which it is not 
holding any directives. 


2. The Directives 

The directives are essentially the actions the plaver wants to take in the course 
of plaving JTLS. They tell the game what unit will take what action at what date, time 
with what resources. When the player begins to create a directive, a template appears 
on the terminal screen listing the attributes that comprise the directive. The directive 
template displays indicate if a data input for a particular attribute is optional or 
mandatory. 

While all directives contain attributes, those attributes only consist of a few 
basic types. The data input to those attributes are the distinguishing factors among 


directives. The most frequently encountered attributes are as follows: 


* REPERENGE A plaver selected name which wniquely identifies the 
GIneGti ver 

e UNIT, SQUADRON The name of the unit or air squadron being given the 
directive. 

° TIME The time for the directive to be implemented by the*@mm 

® DURATIONS The number of davs, hours, and/or minutes the directive 
action 1s to be conducted. 

® COORDINATES The latitudes/longitude pairs which indicate geographic 
pels of interests (for a variety of reasons) in the 
jirective. 


* ROUTE, LOAD, LIST These are utility directives used as attributes in action 
directives. Thev must be_created. before an action 
directive may be’sent to the CEP and implemented. 


tJ 
tJ 


One extremely useful feature of JTLS is the ability of the graphics svstem to 
send names of units and targets and latitude/longitude points to the MIP. When 
graphics is used to enter any of these attributes, the MIP acts as if the player entered 
that data. A shortcoming of this feature is that the player has to establish a 
communications link between the MIP and the graphics station used. This must be 
done at both the player and graphics terminals. 

a. Creating the Action Directive 

To fully understand how the creation of a directive is accomplished, the 
reader should step through the process of directive creation. For example, the AIR 
player would enter the create command. If the player didn’t know the type of 
directives he or she could create or didn’t know the proper syntax for the name of a 
directive, the player could enter a question mark (?). The MIP would then display a 
list of the air directives and associated utility directives. From that list the plaver 
would determine the type of directive to create, enter a “Q” to quit viewing the list, and 
when prompted, enter the name of the directive. 

Upon receiving the directive type, for example AWACS, the MIP would 
| display the AWACS directive template Oi lictcmminal screemricure 2.7. Of the nine 
AWACS attributes, three of them are utility directives. Five of the attributes have 
their data values checked for validity when the verify or send commands are entered to 
the MIP. As the player begins to enter data, each attribute is sequentially entered as a 
single entry or, for the expert player, as a stack of entries. At this point, close 
examination of the AWACS directive creation will show the reader what the MIP is 
doing during the process. 

The first attribute is the Mission. This must be a unique identifier to 
distinguish this directive from other air missions sent to the CEP. The MIP help 
function (the ?) describes the format for the identifier. When verifying or sending the 
directive, the MIP will check the identifier for uniqueness. 

The next attribute is the Squadron. This must be the name of a squadron 
type unit that the air player has under his or her auspices. Only a syntax check ts 
performed here. 

Aircraft is the third attribute. This is a number that cannot exceed the 
number of aircraft in the squadron. The MIP will accept any value during data entry, 
but will match the value to the Squadron when the verify or send commands are 


entered. 
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Figure 2.7 The AWACS Directive Menu. 


Route In and Route Out are attributes which are utility directives. The 
data values of these attributes are the names (identifiers) of routes created separately 
using the Air Route directive. These are checked to deterniune if the routes exist when 
the verify or send commands are entered. 

The Orbit Entry Time attribute is a time for the AWACS nussion to begin 
surveillance in its flight pattern. It is entered as a date-time-group sometime in the 
future. When the game receives the directive it takes into consideration the time it 
takes for the aircraft to reach the orbit pattern and the time it takes to prepare the 
aircraft for launch when determining the validity of this time. If the squadron doesn't 
have enough time to prepare, launch, and fly the aircraft to the orbit pattern by the 
assigned time, the game will advise the plaver of that fact. The only real-time check is 
for syntax. 

The Orbit Duration attribute is a time which tells the game how tong the 
aircraft will orbit in its pattern. This time is checked by the game by comparing it to 
the crew’s maximum allowable flight time and advising the player if the duration is too 
long. The only real-time check is for syntax. 
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The Orbit Pattern is entered as a set of latitude/longitude coordinate pairs. 
The coordinate pairs determine the two end points of an elliptical orbit pattern. The 
only real-time checks are to determine if the points are on the surface of play and for 
syntax. 

The Sensor List is a utility directive. The data value of this attribute is the 
name (identifier) of a list of sensors to be loaded onto and used by the aircraft. The 
sensor list directive is created separately. The attribute is checked to deternune if the 
list exists when the verify or send commands are entered. Since this is also the last 
attribute, the player must enter some command to manipulate the directive. It must be 
noted that this is the “held” directive until the directive is manipulated in some manner 
which “unholds” it. 

b. Creating the Utility Directive. 

Utility directives, as previously mentioned, are created separately from 
action directives. They must exist when the plaver attempts to verify or send to the 
(ea directive which references them. [here are two avenues to create a utility 
directive. One is to create the directive when the player has a blank screen. The other 
is to use the OVERAIIP feature while creating an action directive, suspending the 
plaver’s interaction with the action directive, and allowing the plaver to then create the 
utility directive as if a blank screen existed. 

The Air Route directive has two apparent attributes as shown in Figure 2.8. 
One is the Route ID which is unique to that route. The other is the Latitude and 
Longitude. Yhis coordinate pair is entered for everv point of the air route excepts tiie 
Seeniee. null entry (NE) 1s entered after the last pair. The MIP then prompts the 
player for altitudes for each point. Altitudes are from 500 to 60,000 feet. A null entry 
is then used to quit. | 

The Sensor List directive, Figure 2.9, specifies the sensors to be included in 
a particular sensor package configuration used for various air directives. The two 
attributes of this directive are the List ID and Sensor. The List ID is the unique 
identifier of that list. The sensor is a category of sensors which indicate which type of 
sensors to put into the list. A null entry is used to quit. 

3. Summary 
This section has described the relationships between the programs which 
constitute JTLS, the structures of the Model Interface Program, and the MIP functions 


to be examuned in the prototype. One very important aspect of JTLS which will have 
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Figure 2.8 The Air Route Directive. 


0.000 TO 1 0400002JUL85 0.0000 
~ orev igy. UNCLASSIFIED »..,. PLAYER 2 BLUE COMMANDER |.«...... , NO GRAPHICS STATION, , 
SENSOR.LIST (SL) DIRECTIVE: = | : | 


1. MISSION: XX KKK 


MIP COMMAND: CR SL 
LIST ID: 





Figure 2.9 The Sensor List Directive. 
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an impact on the approach to development of this prototype has not been addressed. 
That is the operating system and sequence of execution in SIMSCRIPT II.5® The 
foundation of the SIMSCRIPT system and the sequence in which JTLS (and the MIP) 
source code is executed is the basic timing routine inherent to SIMSCRIPT, Figure 
Bal): 

Execution of a SIMSCRIPT program begins with the first statement in the 
MAIN program and continues through a series of steps. Resources must be created 
and initialized before they are used by processes. Then the initial processes are 
activated in AZAIN (since SIMSCRIPT requires that something be awaiting execution 
before a simulation commences). A simulation begins when control passes to a system- 
supplied timing routine. This is done by executing the START SIMULATION 
statement. The significance of “something must be awaiting execution” is understood 
when the main program is examined. 

The AJAIN Program contains several processes. One of these is the terminal 
process. This process 1s literally the keyboard read process, 1.e.. how the plaver inputs 
data through the Kevboard to the MIP. When the player uses the Kevboard, the 
process is activated. In terms of the timing routine, this means that the process is 
placed on the pending list and is executed by the timing routine. When the plaver’s 
keyboard 1s idle (the player has used the return key to enter something), the process 1s 
not on the pending list and the timing routine waits for another process to be placed 
on the pending list. During this idle time, the MIP (and operating system) are 
essentially waiting for the player to do something in the interactive mode. Here the 
MIP can still be performing some non-interactive tasks. The significance of this idle 
time created by the MIP is a temptation to the designer to interface directly with the 
MIP rather than the system. It will be demonstrated in Section III that this is not a 


particularly effective approach for development of this prototype. 


D. A COMPARISON OF SOURCE CODE VERSIONS 

To further illustrate the operational behavior of the Model Interface Program. a 
comparison was made between the current version of the MIP source code and the 
source code of a prototype version. In the comparison, a particular objective was 
selected to be accomplished bv the source code. Both versions of source code began at 
the same point and finished with the same result. The current version is written in 


SIMSCRIPT while the prototype version is written in Pascal for operation on the 


a 


START SIMULATION 












ANY 
PROCESSES 
ON PENDING 


LIST? 
we a ues 


EARLIEST (RE)ACTIVATION TIME RETURN 


NO 







EXECUTE PROCESS 
ROUTINE 


Figure 2.10 The Basic SIMSCRIPT Timing Routine. 


Macintosh. Tables 1, 3, 5, and 7 are the current versions of source code for steps 1-4 
respectively. Tables 2, 4, 6, and 8 are the respective prototype versions of source code. 
There are several noticeable differences between the two sets of source code. These 
differences will be pointed out in the following narrative. 

The comparison was made using the creation of a Sensor List directive as the 
Objective of the source code. Both versions of source code begin that process at the 
point where the plaver niust select the directive tvpe. The process then is broken down 
Mat@edesctics Of Steps. Step | is to select the type of directive to be created. In this 
case, Sensor List is selected. Step 2 is to display the directive on the screen. Step 3 is 
to assign an identification reference to the directive. Step 4 is to assign sensor 
packages to the sensor list. The process ends at this point. From here, for example, 
the player could save, verify, or send the completed directive. 

It should be noted that in the current version the steps must be taken in Strict 
sequence. The prototype version permits the reversing of sequence order for steps 3 
and 4. The order of sequence is left strictly to the player's discretion as to what step to 
do when. The player can even go back and redo a step in the prototype version. This 
1s NOt permitted in the current version. To do so the plaver must exit this process after 
it is completed and begin a totally different process. 

A significant assumption was made regarding this process. This should be noted 
so the reader may gain a greater appreciation for the results of the comparison. First, 
it is assumed that the player will always enter syntactically correct, accurate data. 
Thus, format and type checking source code has been left out of the example in the 
current version. The prototvpe incorporates the checking into its code due to the 
nature of its operating system. Except for one case, no prototype case requires anv 
explicit checking. 

It was also assumed that the player would not abort the process. The current 
version source code to do this was also left out. The prototype version did not require 
explicit code as this is inherent to the operation of the system. Also, any code dealing 
with error messages to the player was deleted from the listings. The current version 
has quite a few error messages while the prototype version would only require one for 
this process and its message is inherent in the operating system. The “help command” 
code was also omitted from the current version. It literally is not needed in the 


prototype version. 
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A readily evident result of the comparison now exists and should be mentioned 
despite the risk of prejudicing the overall outcome. The result is that quite a reduction 
of source code can apparently be made between the two versions in the areas of 
checking, process abort, and error messages. This is not a hard and fast result in the 
final outcome however. The reduction in source code now mav be offset by an 
increase in code to perform other functions later. It is the opinion of this author that 
this will not be the case. 

|. Step 1 
The process of selecting the directive type is straight forward. The presentation of 
information to the player requesting a selection is quite different. The current version 
presents a blank screen in the content region (the middle of the screen) while the scroll 
area (the bottom portion of the screen) contains the prompt “directive tvpe:” with a 
blinking cursor a few spaces to the prompt’s right. Here the plaver would begin the 
process by typing in the words “sensor list”. The prototype version presents the plaver 
with a box in the middle of the screen. The box contains a list of directive tvpes which 
are currently available to the plaver. The player moves the cursor to the “sensor list” 
item in the list and selects it. . 

The determination of what type of directive to create has been completed. 
The type selected in both versions was the Sensor List. A breakdown of the step 
reveals several interesting contrasts between the versions. The first is the displav itself. 
The current version puts it’s information for the player near the bottom of the screen. 
While it is out of the way for the main portion of the screen, it is also “out of the way” 
in terms of the player’s visual focal point. In general, a person’s initial focal point is 
the middle of a display and then the person examines the displav area to seek out the 
required informiation. | 

The prototype version places it’s display in the middle of the screen which is the 
player's initial focal point. The player doesn’t have to search for the information. This 
contrast is subtle, but nonetheless significant throughout the process and in terms of 
information transfer to the plaver. 

The player’s actions also represent a contrast worth review. The current 
version requires the player to tvpe in characters from the keyboard. The prototype 
version requires the player to position the cursor and press a button (an item click), an 
action which is alwavs at the player's fingertips. The two actions are quite different 


and ease of performance for typing varies significantly from plaver to player. The 
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TABLE 1 
STEP 1 - CURRENT VERSION 


Determine.the.Directive.Type 
Use 55 for input 


Ect prompt.v = "Directive Type:" 
Now Interpret.the.Directive.Meaning 
Given 100 


Yielding meaning 
CC_number = 100 
Find the first Command_Context(CC_Number) in Vocabulary_ 
Do until terminated 
Now Determine. the.Response 
Until finished do 
If Input_Line is not empty 
Use buffer for input 
Remove first Input_Word from Input_Line 
Let Response_ = BERET: .£(IW_Text (Input_Word) ) 
he teuds h..Ource W_Source(Input_Word) 
Destroy Input_Word 
Return 
Else If Last.Source + 0 
If Last.Source = I.Terminal 
Activate Terminal Process 
Else use 55 for input 
Now Write.A.Text. Seed 
Give. OROMD Uae so, lO. 0 
Wsiemo en ie baeror input 
Activate Graphics Process 
Suspend x ) 
Loop 
IF Directive_ ~# 0 
Now Display.a.List 
Given Dir_Menu, 2; 
Let Menu_Status = "display" 
Let Lines = Dim.f(Dir Hoe 
Let eet .~page = lines-2- 
If lines’ 
For I= 1 i lines do 
Nowe Wrilceed. Lextes en tng 
Given Dir “Menu(1), Zth—t 10,0 
Call LIBSPut_Screen(Descr. F(Text. String) 


line+1,column,local. graphics) 
Return 


Let Menu_Status = "menu!" 
For each Recognized_Command in CC_SET_OF_ENTRIES(CC_Number) 


With RC_Name = "Sensor List" or RC _Alternate _Name = "SL!"! 
Find the first case 


Let meaning = RC_Meaning_No (* = 706 *) 
eenelitayg: 


preference of one action over the other varies according to the individual's tastes. 


These two contrasts are again subtle but their significance, especially typing, is closely 
tied to an individual’s physical skills. 


on 


TABLE 2 
SEPT Ine TOT yice 


ModalDialog(NIL, theItem) ; 
Il := GetDItem (theDialog, theItem 
I2 := GetNewControl (Il, themes oot 
DPLongName := GetCTitle (12, title 
DisposDialog (theDialog) ; 


Handle, Display); 


, 





The most significant contrast is in the source of the data. The current version 
requires the plaver to be the source of data and it is entered via the keyboard. The 
prototype version provides the source of data (in all but one case) via computer 
memory with input made through the item click. Since the input is made through 
computer memory there is no chance of a syntax error and less of a burden upon the 
player to enumerate the choices of directive types available to him. The prototype 
enumerates the choices and makes a syntactically correct entry of data to the process. 

In summarizing the contrasts of versions in the first step, it is worth noting 
the amount of source code required to perform the step. The prototype performs the 
same step with only an estimated 15% of the source code needed in the ¢unsem: 
version. The primary difference in the amount of code is due to the large amount of 
current version code required to display, retrieve, and interpret information written to 
the screen from the keyboard. The prototvpe version gains this advantage bv using 
operating system functions and procedures to perform comprehensive accomplishment 
of tasks. Another reason is that fewer tasks are required in the prototype version due 
to the nature of the operating system. It will be evident as the process continues that 
the contrasts of display, player actions, and source of data will be factors in each step 
of the process. The reader is cautioned that task accomplishment may not always be a 


prototype advantage in the performance of the process. Now step 2 is ready to be 


done. 
2. Step 2 
This step in the process displays the directive Sensor List on the screen. The 
display includes the directive title, the directive’s attribute and the attribute’s field 


codes. The display is oriented toward the middle of the screen on both versions’ 
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Abie 3 
STEP 2- CURRENT VERSION 


For each Directive_Prototype with DP_Meaning = 706 
Find the first case 
Now Create.the.Directive 
Now Erase.the.Menu.Area 
Por lv= 2. to 17 
Call LIBSERASE_LINE(I, 1) 
Let Menu_Status = "blank" 
Create a Directive_ 
Store Directive _Prototype in 0.DP_Directives_Set 
Reserve Menu Array as size = 15 
Store DP_Menu_Template in Template Array 
For I =1 to 15 
Let Menu(I) = Template(T) 
Store Menu(l to 15) in Dir_Menu 
Now Display. jonaae 
Given Menu(I), 
Let Menu_ see = "display" 
Meee lines = Dim. F(wenu(t)) 
Let Patan Sede ._page = 18- 
If lines 
Sole Jeeta a TS 
Now Write.a.Text.String 
Given List(I), S+l-wal 20, 0 
Call LIBSPut “Screen(Descr. F(Text. Suielicy geal inet ie 
column, local.graphics) 
Return 
Let Menu_Status = "menu! 





display lavout. In both versions the step begins with a directive meaning and then 
searches the data structures for a directive prototype having a meaning of “sensor list”. 
When the code finds that data, it displays it on the screen. At this point the versions 
begin to differ. 

The current version first calls a VAX library routine to erase the screen. It 
then develops a generic display template consisting of 15 lines. Once the template is 
made, the current version gets each attribute of the directive prototvpe and draws it to 
the screen, line by line, according to the AP_Line and AP Coll values of each 
attribute. When each line is drawn the display is complete. 

The prototype version begins by creating a pointer to a new directive and then 
invoking the directive display module. Every directive reads in a generic display 
template and, for each display control item, changes the control's generic title text to 


the attribute's menu prompt. At the same time each control item is changed, it makes 
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TABLE 4 
SREP 2 SRROTO tie 


For Directive Prototype with DPLongName do 
NewDirective = |Directive; 
Directive Display; . 
N := NumberAP; . the total number of attributes *) 


For t= 1 tor leeao 
GetNewControl(ID, theWindow) ; 
For J = 1 to N do 
If I = J then 
SetCTitle(J, AP Prompt); 
ShowControl (J); 
Else For I > N do 
For DP Attribute Prototype (I) do 
HideControl(1 
HiliteControl(t, 254);(* disables control *) 
DrawControls(theWindow) ; 





it visible. For each control item not changed that control item is made invisible and 
inactive. The module then draws the display to the screen in its completed form. 

The contrasts here are speed and amont of code. Ihe Specie 
inconsequential here since the prototype uses the same repetitive loop as the current 
version to produce the display. However, speed could be tilted considerably in favor of 
the prototype version if each specific directive display existed in a resource file and was 
explicitly called when needed. This would result in a much faster time @ioniie 
Macintosh to draw the display to the screen (this will be discussed later in this thesis). 
The current version has no capability to do this. 

The other contrast. amount of source code, again favors the prototype 
version. The reduction of an estimated 35% of the current version is primarily due to 
graphics overhead on the VAX. For example, a repetitive loop is used to erase the 
VAX screen line-by-line, another loop is used to create the display template line-by- 
line, and finally a repetitive loop is used to draw the display. The prototype version 
uses a single, doubled-nested repetitive loop to assign text to display items and then 
draw the display to the screen. The ability of the prototype to do this in a simpler 
manner than the current version is owed to the operating svstem functions and 


procedures comprehensively performing tasks. 


The summary of contrasts for step 2 again results in a favorable rating of the 
prototype over the current version. This leads to step 3. Although the prototype 
version would permit the execution of step 4 at this time, for simplicity in conducting 
this comparison, both versions will perform the same step. 

3. Step 3 

This step deals with getting an ID for the directive. Keeping in mind it must 
be unique, the assumption made here (for simplicity) is that the plaver will enter a 
unique ID. In this step both versions differ from the start. Here the prototype version 
Waits for an event to occur while the current version must write the prompt to the 
screen. The advantage is immediately tilted toward the prototype version. The process 
will indicate why. 

The current version begins by sequentially stepping through the attributes and 
stops at the first one. It reads the AP_Menu_prompt, “Il. List ID:”, and rewrites it 
over the existing “I. List [D” but this time emphasizes it graphically. It then draws 
the AP_Create Prompt, with a flashing cursor as emphasis, into the scroll area at the 
bottom of the screen. Then, invoking the attribute’s create routine, it awaits the 
player's keyboard response. Once the player inputs a string, the current version checks 
to make sure it is not more than 8 characters. If it is more than 8, an error message is 
generated and the prompt in the scroll area is rewritten. (This check was intentionally 
left in the process due to its significance in the comparison.) If the response 1s 
acceptable, it is written into the field code space replacing the attribute field code. The 
current version then deemphasizes the AP menu prompt and then invokes the Retrieve 
the Directive Attributes module. Here it reads the attribute’s word integer and assigns 
the ID to the appropriate word in Directive_. 

The prototvpe version begins by waiting for a player action known as an 
event. 1m this case, a click inthe “{. List ID: item. The prototype version determines 
an event occurred, what to do to handle the event, finds out the location of the click 
event, and then invokes the CRRGet module for the given AP Create Routine. Now 
the prototype gets a dialog box and draws it in the center of the screen. The dialog 
box includes a text edit rectangle, 8 spaces long, with a flashing cursor in it. Now the 
prototype waits for the player to input a string, which is also another event. It 
determines an event occurred, that it was a keypress event (of a legal character), and 
enters the character string into the text edit rectangle. Note that since the text edit 


rectangle is only 8 spaces long it implies the plaver can never enter a string that 1s too 
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TABIEE 
STEP 3- CURRENT VERSION 


For each Attribute_Prototype in DP_Attributes_Set(Sensor_List )Do 
Use 55 for input 
Let prompt.V = AP_Create_Prompt (%¥ "List ID:" #) 
Use buffer for input 
Now Write.a.Text.String 
Given AP_Menu_Prompt, AP_Line, AP_Coll,» 0», Emphasize_ 
Call LIB$Put_Screen( Descr.F( AP_Menu_Prompt), AP_Line, AP_Coll, 
0, Emphasize_) 
Write AP_Arguments_String as text 
Let Subroutine = CRR_Name( AP_Create_Routine ) 
Call Get.a.Directive.Identifier 
Read Search.Code 
Until finished do 
Now Determine.a.Response 
Until finished do 
If Input_Line is not empty 
Use buffer for input 
Remove first Input_Word from Input_Line 
- Let Response_ = Upper.Fl( IW_Text( Input_Word) ) 
Let Last.Source = IW_Sourcel Input_Word) ) 
Destroy Input_Word 
Return 
Else 
If Last.Source * 0 
If Last.Source = I.Terminal 
Activate Terminal Process 
Else use 55 for input ° 
Now Write.a.Text.String 
Given prompt.v, 23, 1, 0, 0 
Use buffer for input 
Activate Graphics Process 
Suspend 
Loop 
If Response_ = "NE" 
Now write.a.Bottom.Line 
Given "A null entry is not valid" 
Call LIB$Set_Cursor(2¢, 1) 
Call LIB$Put_Screen(Descr.F(Concat.F(text.string, CR_LF)); 
24, 1, O) 
Now SKip.Rest.Of.Line 
For each Input_Word in Input_Line do 
Remove Input_Word from Input_Line 
Destroy Input_Word 
Loop 
Cycle 
Otherwise 
If Length. F(Response_) > 8 
Now Write.a Bottom.Line 
Given "ID can be no more than 8 characters" 
Call LIB$Set_Cursor(24¢, 13 
Call LIBSPut_Screen( Descr.F(Concat.F( text.string, CR_LF)), 
24, 1, 0) 
Now SKip.Rest.Of.Line 
For each Input_Word in Input_Line do 
Remove Input_Word from Input_Line 
Destroy Input_Word 
Loop 
Cycle 
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TABLE 5 
STEP 3- CURRENT VERSION (CONT'D.) 


If Length.F(Response_) S 8 
For I = 1 to Length. F{(Response_) do 
Let This.Char = Substr.F(Response_, I, 1) 
If This.Char = "&" or This.Char = "#"' 
Write This.Char as /, 
"Entry cannot contain" This.Char "character" 
Read Output.Line 
Now Write.a Bottom.Line 
Given Output.Line 
Call LIB$Set_Cursor(24¢, 1) 
Call LIB$Put_Screen( Descr.F{Concat.F{(text.string, CR_LF)), 
24, 1, 0) 
Now Skip.Rest.Of. Line 
For each Input_WNord in Input _Line do 
Remove Input_Word from Input_Line 
Destroy Input_Word 
Loop 
Let Bad.Char = 1 
Leave 
Loop 
If Bad.Char 
Bad. Char 
Cycle 
Write Response_ as text 
If Menu_status = "menu" 
, Now Write.a.Text.String 
Given Response_, AP_Line» AP_Col2, 8, 0 
Call LIB$SPut_Screen (Descr.F(Response), 
AP_Line,» AP_Col2, 8, 0) 
Now Replace. the.Menu. Field 
Given Response_. 
Now Write.a.Text.String 
Given AP_Menu_Prompt, AP_Line, AP_Coll, 0, 0 
Call LIBS$Put_Screen(Descr.F(AP_Menu_Prompt), AP_Line,> 
AP_Coll, 0, 0) 
Now Retrieve. the.Directive.Attributes 
For each Word_Indicator in Word_List(Attribute_Prototype) do 
Case of (WI_Integer ) 
(1) Read Dir_I0O 
Loop 
Loop (® to do next attribute *) 
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long and thus never commit an error. The transparent error checking will not accept 
the player’s entry of an illegal character or more than 8 legal characters. The dialog 
box then assigns the AP field code the value of the string, moves the graphics pen to 
the field code space on the screen, and draws the string in as the field code. The 
prototype version then invokes Retrieve the Directive Attributes, reads the attribute's 


word integer, and assigns the ID to the appropriate word in Directive. 
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TABLE 6 
STEP 3] PROGOP wee 


GetNextEvent (theEvent, everyEvent) ; 
MouseClic 
HandleEvent; 
HandleClick; . 
K := FindControl(thePoint, theWindow, 
whichControl) ; 
For DP Attribute Prototype (K) do 
L := AP Create Routine (K); 
CRRGet (L); (* Get an ID 
DialogPtr := GetNewDialog (ID, dStorage, 
theWindow) ; 
TEPtr := TENew (destRect, viewRect) ; 
GetNextEvent; 
Keypress; 
HandleEvent; 
TEKe (Ke , TEPtr); 
ModalDialo g(theIDFilter, ItemHit); 
theDFilter(theDiaiog, theEvent, ItemHit); 
theIDFilter := Fa ‘se; 
ItemHIt : Q; 
iP peng en. F(string) = 8 then 
Case theEvent.What of 
Keydown, Autokey : 
Case of (theEvent.Message mod ao) Of 
| 1) (A..Z, 0..9, bkspc) : 

d 2meOE (teec. 0..9, bksaene 
theIDFiiter := True; 
systemBeep; 

Return; 
Else (* for Length.F(string) > 8 *) 
If theEvent.Message mod 256 = bkspc then 
theIDFilter := False; 
Else the IDFilter := True 
Systempecr- 
Return; 
novets (ae Line, RP CoLS), 
MoveTo(AP Line, AP Co (x AP Line & AP Col2 converted 
to pixel units 
DrawString(AP =e d Code (K)); 
Retrieve Directive Attributes; 
For 9 = Word Integer do 
Case of Word Indicator (2) 
e(K); 


DirID := AP Field Co (420 = 71 >) 


In this step the contrast focuses on the extra code required by the current 
version to do the process, the display of the focal point, and ease of input for the 
plaver. Once again the advantage pendulum has swung over to the prototype version. 
The first contrast deals with the fact that the current version is constantly doing 


graphics tasks of emphasizing, changing, and rewriting. The fact this is done so many 


times encumbers the process in the current version while the prototype version 
performs it’s tasks once. The prototype version reduces code execution an estimated 
58% from the current version. 

A significant contrast is the display focal point. Again the prototype version 
centers it’s focal point immediately grabbing the plaver’s attention. The current 
version creates two focal points which could be distracting. The first focal point is the 
emphasized attribute positioned in the mid-upper left portion of the screen. The 
second focal point is the pronipt and cursor down in the screen's scroll area. This is 
really where the player wants to focus his attention. The advantage regarding this 
contrast is with the prototype version. 

The final point in contrasting the versions 1s the ease of player input. In the 
prototype version the player had to select the attribute himself vice having it done for 
him automatically in a predetermined sequence. This is fairly negligible when 
compared to the actual entry of data such as the ID string. Here the prototvpe 
ensured the player kept the [D within limits while the current version could permut the 
player to commit an error. This subtle contrast favors the prototype version. 

Finally, both versions are ready to enter their list of- sensor packages. 
Considering the wide margin of advantage of the prototvpe version compared to the 
current version, the final outcome of the comparison could be predicted. However, 
step 4 should be examined to complete the process comparison. — 

4. Step 4 

This step is a lengthy process for both versions of source code. Similar 
processes occur in that both invoke the appropriate create routine, get the sensor 
package names and display all of them, and invoke Retrieve the Directive Attributes. 
The similarities end there. 

The current version expends a lot of code doing graphics displays, 
emphasizing, writing prompts, determining responses, rewriting prompts, and 
deemphasizing. In the end, the current version uses two focal points (moving back and 
forth between the two points), forces the player to explicitly input whether or not a 
displaved sensor package is assigned to the list, and requires the player to explicitly 
close out the list of sensor packages. 

The prototype behaves as expected. It waits for an event, in this case the 
click of the item “2. Sensor”, draws a dialog box onto the center of the screen with all 


the sensor package names included in the box. It also invokes the List Control module 


by 


TABLE 7 
STEP 4 - CURRENT VERSION 


Use 55 for input 
Let prompt.V = AP_Create_Prompt 
Use buffer for input 
Now Write.a.Text.String 
Given AP_Menu_Prompt, AP_Line» AP_Coll, 0, Emphasize_ 
Call LIB$Put_Screen( Descr.F(AP_Menu_Prompt), AP_line, AP_Coll, OQ,» 
 Emphasize_) 
Write AP_Arguments_String as text 
Let Subroutine = CRR_Name(AP_Create_Routine ) 
Call Get.a.Sensor.List 
If Saved.Flag = 0 
Let Saved.Flag = 1 
Create Command_Context 
Let CC_Number = 1120 
Let CC_Message = "Enter (something) or NE to end list." 
For each Sensor_Package 
With SP_Name = " " do 
Create a Recognized_Command 
Let RC_Name = "NE" 
Let RC_Meaning_No = 100 
File Recognized_Command in CC_SET_OF_ENTRIES 
File Command_Context in Vocabulary_ 
Store Dir_Menu in Menu (1 to 15) 
Let Menu_Status = "List" 
Let Line = AP_Line + 2 
Let Items.in.List = 0 
Until finished do 
If Line = 18 - 2 
Let Line = AP_Line + 2 
Use 55 for input 
Let prompt.V = "Name of category:": 
Now Interpret. the. Vocabulary.Entry 
Given CC_Number = 1120 
Find Command_Context(1120 ) 
Until finished do 
Now Determine. the.Response 
Until finished do 
If Input_Line is not empty 
Use buffer for input 
Remove first Input_Word from Input_Line 
Let Response_ = Upper. F(IW_Text( Input_Word) ) 
Let Last.Source = IW_Sourcel Input_Word)) 
Destroy Input_Word 
Return 
Else 
If Last.Source + 0 
If Last.Source = I.Terminal 
Activate Terminal Process 
Else use 55 for input 
Now Write.a.Text.String 
Given prompt.v, 23, 1, 0, 0 
Use buffer for input 
Activate Graphics Process 
Suspend 
Loop 
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TAI =) 
STEP 4- CURRENT VERSION (CONT’D.) 


If Q@=l 
Let Q = 0 
If Directive. * 0 


Now Display.a.List 
Given Dir_Menu, 2 
Let Menu_Status = "display" 
Let Lines = Dim. F(List(*)) 
Let Lines.per.page = 14 
If Lines S 15 
For I = 1 to Lines 
Now Write.a.Text.String 
Given List(I), 3+I-l; 1; 0; 0 
Call LIB$Put_Screen(Descr.F(List(I)), 3+I-1, 1, 0, 0) 
Return - 
Menu_Status = "menu" 
For Recognized_Command if CC_SET_OF_ENTRIES( 1120) 
With RC_Name = Response_ or RC_Alternate_Name = Response_ 
Find the first case 
Let meaning = RC_Meaning_No 
If meaning = 100 
Leave 
Let Substr.F(Menu_(Line-1), AP_Coll, 15) = SP_Namel meaning) 
Now Write.a.Text.String 
Given SP_Name(meaning), line, AP_Coll, 15, 0 
Call LIBS$Put_Screen(Descr.F(SP_Name), line, AP_Coll, 15, 0) 
Let Items.in.List = 1 
Create an Element_ 
Index(Element_) = meaning 
File Element_ in Vector_ 
Add 1 to line 
Loop 
Reserve Rarray(*) as N.Sensor_Package 
Reserve TArray(*) as N.Sensor_Package 
Let Categories.per.page = 18-4-3 
For each Sensor_Package with SP_Name = " " 
Add 1 to Total.Sensor.Packages.On.This.Side 
Add 1 to Sensor.Packages.On.This.Side 
For each Element_ in Vector_ 
With Index(Element_) = Sensor_Package 
Find the first case 
If found 
RArray(Sensor_Package ) 
TArray(Sensor_Package ) 
Else 
TArray(Sensor_Package) = "no" 
If Sensor.Packages.This.Side SS Categories .Per.Page 
Let Substr.F(Menul AP_Line+Sensor.Packages.This.Side), 
AP_Coll, 15) = SP_Name 
Let Substr.F(Menul AP_Line+Sensor.Packages.This.Side)>, 
AP_Col2, 3) = TArray 
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Loop 
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TABLE 7 
STEP 4=GURRENT VERSION(GONT 


Let Header = ITOT.F(N.Sensor_Package) 
Write Header as text 
For each Sensor_Package 
Write RArray(Sensor_Package) 
Release RArray(*) 
Now Empty.the.Vector — 
For each Element... in Vector_ do 
Remove Element_ from Vector_ 
Destroy Elements 
Now Write.a.leéxesering 
Given AP_Menu_Prompt, AP_Line, AP_Coll, 0, 0 
Call LIBSPut_Screen | . 
Now Retrieve.the.Directive.Attributes 
Given WI_Integer : 
Case of(WI_Integer) 
(53) Read Dim 
Store 0 in Real_Array(Dim) 
Reserve Real_Array(Dim) 
For i-= 1 tovban 
Read Real_Array(I) . . 
Store Real_Array(*) in Dir_Genericl_DPointer 
Cycle 





assigning each package a check box control. It then waits for the player to “check” (an 
item click) the sensor packages to be listed. The prototvpe version automatically 
determines that non-checked sensor packages do not go into the list and automatically 
closes out the list. It then assigns attributes to the appropriate words in Directive the 
same as the current version does. 

The Sensor List directive is now complete. Again contrasts between the 
versions gives the prototvpe the advantage. Amount of code. display focal point, ease 
of input for the player constitute the areas of difference between the two versions. 
Amount of code contrasts resulted in the prototvpe version having an estimated 65% 
reduction in lines of code executed from the current version. Repetition of graphics 
code and use of numerous data structure elements not required in the prototype 
account for the difference and the poor rating of the current version. 

The focal point of the display heavily favors the prototype version. It’s 
display is centered on the screen and behaves exactly as the other prototype displays. 
The current version, on the other hand, continually switched the focal point of the 
player's attention from mid-screen (to see what was displayed) to the prompt in the 


scroll area (to make an input). This is distracting and time consuming. 
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TABLE 8 
Seno - PROTOTYPE 


GetNextEvent 
MouseClick; 
HandleEvent; 
HandleClick; . 
K := FindControl(thePoint, theWindow, 
whichControl) ; 
For DP Attribute Prototype ro do 
L := AP Create Routine 
CRRGet (L); (* get a ee package *) 
List Control(ME) ; 
DialogPtr := GetNewDialog(ID, 
dStorage, theWindow) ; 
Until Sensor Package EOF do 
M := SP number 
SetIText(M, SP ‘Name); 
Repeat; 
For P := to M do 
ModalDialog(NIL, thelItem(P)); 
Il := GetDI tem(thedialog, theItem, 
Handle, Display); 
I2 := Beene R COREE Ol (11, eel 
AP Lae Code (index) := GetCTitle(I2 
title ' 
MoveTo(AP Line + 1 line, AP Col2 + — 
4 spaces); (* lines & Spaces converted 
to pixel units *) 
DisposDialog(theDialog) ; 
Index := Index + 1; 
Retrieve Directive ‘Attributes; 
Fob — Word Integer do (* 0 = 53 *) 
Case of Word Indicator (Q 
For Dim = 1 to M 
For Num = 1 to Index do 
If Sensor Package(Dim) = AP Field 
Code (Num) then 
Real Array (Dim m) := 1.0; 


gapn ey Mean) := "Yes! 
Real Array van := 0.0; 
WRG) ely ees any! 
Dir Genericl BEoneee := TReal Array; 


For Set of Directives 
with DP Meaning = Sensor List(meaning) 
Set of Directives := NewDirective| .Directive; 


The final contrast is ease of use for the plaver. The player enters data through 
the keyboard, is subject to committing errors, and must make repeated inputs when 
using the current version. The prototype version only requires item clicks by the 
player; no errors, no distractions, just a simple process. The advantage here again 


heavily favors the prototype version. 


In summarizing the entire process, a simplified one at that, the prototype 
version is distinctly easier to use for the player, a considerable savings of executed 
source code, and a better presenter of information than the current version. Based 
upon these comparisons of the two versions the creation of a graphically oriented 
replacement for the MIP is desireable. The following material is predicated upon the 


design of such a prototype. 
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Ill. THE PROTOTYPE OF THE VISUAL INTERFACE 


A. THE METHODOLOGY OF DESIGN 
1. The Basics of a Window Management System 

Window management systems are relatively new to computer systems, just 
barely a decade old. The computer industry as a whole did not accept window 
management from the outset, but people interested in computer graphics have kept the 
concept alive. Attempts at widespread usage of window management systems failed 
until Apple introduced their Macintosh. The Macintosh has gained widespread 
acceptance-and 1s particularly a favorite of casual users. The reason for this is three- 
fold: 


1) Apple’ specifically concentrated on making the user interface as simple as 
possible through the use of common visual symbols and association. 


2) The company applied an extremely good and technically sound graphics 
package to the system. 


3) Apple took the best ideas of other attempts at developing window 
management systems and applied them to their design. 


As such, the Apple Macintosh has come to be accepted as the “unofficial” standard for 

the methodology of window management systems [Ref. 6], and it’s interface is the 

foundation of this prototype design. | ° 
a. The Infrastructure of the Macintosh Interface 

The Macintosh has been described as a universe with its own set of laws, 
similar to the laws of physics, that describe the standard behavior of objects. These 
“laws” are consistent which has a direct impact on how an application, and this 
prototype, is designed. Thus, the application should be flat and user driven (t1.e. 
modeless) as opposed to being tree-structured and menu-driven. This allows the user 
to focus on what the application does, instead of how it does it. [Ref. 7] 

This “modeless” environment allows the user to do anything that makes 
sense at anv time. This means the user is in control of what is going on with the 
computer and the application. It also means, in general, that if the user performs an 
action that makes “sense” then the “laws of nature” are not violated and the user 
doesn't get penalized for doing something wrong. This is a very desireable feature in 


an application and is the basis for the Macintosh User Interface Standard. [Ref. 8] 
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The Macintosh User Interface Standard has nine basic concepts: 


e Applications These enable the iser tO manipwlaie 
information. 

e Documents These _ contain information which the 
application manipulates. 

e Views These present information. 

¢ Commands These alter the information in specific wavs. 


e The Finder’s Desktop Metaphor This, provides an image of what is in 
Macintosh’s .memory _and is a_ working 
environment for the information manipulation 
carried out on the Macintosh. 


e Windows These divide a portion of the Macintosh screen 
for a portion of the view. 

e Selections These identify those portions of the information 
that can. be affected by certain subsequent 
commands. 

e Editing Conventions These govern the manner of specifying 
selections. 

e¢ Fonts These provide a basis for manipulating text 
appearance. 


The reader may gain a comprehensive understanding of the Macintosh User Interface 
Standard by reading Inside Macintosh. | 
b. The Application of the Interface Standards 

These concepts result in the user being presented. on the screen, a variety 
of graphic objects which behave in expected ways and represent information which the 
user understands. The user will see at the top of the screen a menu bar containing 
classes of commands. At the user’s fingertips is a mouse whose movements cause the 
movenients of a cursor on the screen. The user can position the cursor over a menu 
title, press the mouse button down and, while pressing it down, “pull-down” a list of 
menu items. These cursor movements which “pull down” something are commonly 
referred to as dragging and have a direct correlation to “dragging” the mouse across a 
table or desktop. If the mouse button is released over any menu item, that item is 
selected as the command to be performed. The action of pressing and releasing the 
mouse button is also known as clicking. Sometimes these menu items are “dinymed” 
and cannot be chosen, indicating they cannot be performed at that time by the 
application. 

The user also sees a window which presents information such as a document 
or a message. The window may be “active” and have its objects manipulated. More 


than one window can be presented at a time but only one may be active. The window 
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presents a view of its contents but not all of its contents may be visible. If so, the user 
must scroll through the information to see it all. The user may move the cursor all 
around the window and click in the window causing something to happen which the 
user would expect to happen. When finished with the window, the user can click in the 
close box and the window disappears. As with all user actions, the user sees and 
identifies some object, performs some action with regards to the object, and gets an 
expected result. This process happens because of the use of a set of Macintosh 
operating system routines. | 
These routines are divided by function and are commonly called managers. 
The various managers used in most applications reside in the operating system or the 
User Interface Toolbox. The operating system performs such basic tasks as input, 
output, memory management, and interrupt handling. The user interface toolbox, a 
level above the operating system, helps implement the standard Macintosh user 
interface. It is through the variety of managers that the prototvpe is developed. The 
managers, all logically named, perform basic tasks as defined by Inside Macintosh 
eet. 9]. [hey are: 
e Resource — This manager performs operations on, and allows access to. 
Hee cepucauion resources such as ea fonts, icons, 
¢ QuickDraw The. heart of the Macintosh user interface, this manager 
performs all graphics operations including. drawing 
something on the screen very quickly. It interfaces with 
many of the other toolbox managers. 


e Font Manager This manager supports the use of the various character fonts 
when text 1s drawn by QuickDraw. 


e Event Manager The Event Manager monitors the user’s actions and 
coordinates the actions of the other toolbox routines. 


e Window Manager This manager controls the creation, manipulation and 
disposal of windows. 


e Control Manager The Control Manager handles special objects on the screen 
With swhich the user, wsing the miouse. can cause instant 
action with graphic results or change settings to modify a 
future action. 


e Menu Manager This manager creates sets of menus and allows the user to 
choose from the commands in those menus. 


sevext Edit This manager handles the basic text formatting and editing 
capabilities in an application. 


e Dialog Manager This manager allows for implementing dialog boxes and the 
alert. mechanism. two means of communication between the 
application and the end user. 


e Desk Manager The Desk. Manager supports the use of desk accessories 
(nuni-applications) in an application. 
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e Scrap Manager This, manager. supports cutting and pasting among 
apphcations and desk accessories. 


¢ Toolbox Utihties These are a set of routines and data tvpes. that (ye sone 
generallv useful. operations, such as fixed-point arithmetic, 
String manipulation, and logical operations on bits. 

e Memory Manager This manager dynamically allocates and releases memorv for 
use by the apphcation and other parts of the operating 
svsteni. 


¢ File Manager The File Manager handles file input and output for the 
operating system. 


¢ Device Manager The Device Manager manages the input and output devices 
for the operating svstem. 


2. The Correlation of the MIP and the Macintosh User Interface. 

The design of any application must consider the operating system to be used 
as well as meeting the user's needs. The Macintosh operating system supports the use 
of high-level programming languages, primarily Pascal. One particularly fast and 
efficient version of Pascal is Turbo Pascal© by Borland, Inc. Turbo Pascal was this 
author's choice as the high-level programming language to use for testing some of the 
concepts of design used in developing this prototvpe. Turbo Pascal was deemed 
capable of meeting all requirements of the MIP in terms of functionability. 

a. The Restructured Data Flow Diagram 

A goal of any application design should be to provide for the smooth flow 
of data. Figure 2.3 identified a bottleneck of data flow. A distinct advantage of using 
the visual interface is that this bottleneck can be effectivelv removed while still leaving 
the “flow of control” with the user. Figure 3.1 depicts the changes of data flow. The 
player initiates the flow of data and subsequently controls it all, yet provides little or 
no data input. The primary difference between this diagram and the first one is that 
this design use the stored information available to.it, primarily the Plaver Initialization 
File (PIF), to transform data rather than the player providing the data to be 
transformed. The application thus runs smoother, information-wise. 

A refinement to the data flow diagram explicitly shows how this is 
supported, Figure 3.2. The transformation prepare directive is broken down into three - 
layers. Each transformation’s refinement is contained within the dotted lines in Figure 
3.2. Note that for each layer the information inputs and outputs are the same 
respectively. The input to the transformation is the create command and the output is 
the completed directive. In layer two, the transformation is broken down into three 
transformations which are ger the directive type, get the directive attributes and assign 


attribute values. Ail the information needed is retrieved from stored informiation. The 
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attribute information is wholly acquired from the PIF. In layer three, refinement of 
the transformation entitled assign attribute values results in the transformations find 
ranges/choices available and assign choice to attribute. In following the data flow, the 
data always exists in the flow pattern and the player controls the data by selecting a 
choice. The player inputs the create command, is presented a list of directives, and 
selects one. That directive’s attributes are presented, and for each attribute the player 
is presented a range or choice of values from the PIF and selects one to assign as the 
attribute’s value. When all attributes have been assigned values (as required) the 
directive is complete. It is in this refinement that the MIP becomes an application of 
the visual interface. 
b. The Conversion of SIMSCRIPT to Pascal 
(1) The Data Structures. The source code of the MIP is lengthy and 

contains a large number of data structures of the type mentioned earlier in this thesis. 
There appears to be a strong correlation of these data structures to Pascal data 
structures. A SIMSCRIPT set is equivalent to a Pascal linked list. An entity 1s 
equivalent to a record or an array, dependent upon the particular entity. In most 
cases, an entity is of multiple data tvpes so a record is an appropriate structure. An 
attribute 1s equivalent to a pointer or a variable of various types (real, double extended, 
‘integer, character, enumerated, subrange), or possibly even an array or record. 
Temporary entities are dynamically created during the course of the execution of the 
MIP, thus they would be created in Pascal as an addition to a linked list. Permanent 
entities ¢xist throughout the course of the execution. These are created during 
initialization and their size is known. To correlate this to Pascal, the entities would be 
subscripted variables of an array of records since the size would be the dimension of the 
array. While SIMSCRIPT automatically provides some pointers and flags to indicate 
membership in a set Or ownership of an entity, these would have to be declared as 
fields of a Pascal record. 

An exainple of this correlation is shown im Figure 93733ueum 
SIMSCRIPT, the AWACS directive needed all the entities shown in the figure as 
records. The Pascal version shows the linked lists, the records, and the data fields 
needed to create the AWACS directive. This correlation can generally be assigned 
across the board for all the MIP data structures used by the visual interface. 

It must be noted that all the data structures used for VAX terminal 


graphics and for alert;error messages are not needed for the visual interface 


Records Variables 
Directive Prototype Simulation Time 


Attribute Prototype Latitude East 
Directive Latitude West 
Unit Longitude North 
Aircraft Longitude South 
Emitter Suite Create Routine 
Sensor Package 


NOTE: This does not include graphics data. 





Figure 3.3. The AWACS Directive PASCAL Data Structures. 


application. The data contained in these structures is necessary due to the operating 
svstem used. The data structures necessary for the Macintosh operating system are 
inherent to it or can be explicitly addressed in the code or resource files. Specifically, 
the entities are interval. database_, interrupt_, input_word, element_, command_context, 
recognized_command, CEP_parameter_index, long_word, menu_line, and held_directive. 
There are also several variables not needed which generally pertain to terminal 
graphics. Should any question arise about the purpose of and necessity for any 
SIMSCRIPT data structures to be used in the visual interface, the reader should refer 
to the source code and the MIP Software Engineering Maintenance Manual, Reference 
10. 

(2) The Source Code. SIMSCRIPT TI.5© was designed to support 
structured programming and modularity as applications’ of software engineering 
(Ref. 1: p. i]. As such, many of the coding conventions of the SIMSCRIPT language 
are simular to the language constructs of the high-level programiming languages such as 
Pascal. The if-then-else, do-while, and case statements are examples of condition 
Statements common to both languages. 

Reserve, define, mode, and dimension are typical assignment statements 
in SIMSCRIPT, but must be handled through Pascal declaration and assignment 


Statements accordingly. The use of boolean arguments is common to both languages 
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and the operators are the same. A brief review of the SIMSCRIPT reference would 
allow any programmer with just moderate Pascal experience the ability to read and 
follow the source code. 
c. The Prototype of the MIP Functions 
(1) The Commands. 


to menu items in the Macintosh environment. The commands can be grouped by class 


The commands have a direct functional correlation 


in nearly all cases. The classes of commands are implemented as menu titles. The few 
which are not associated closely with a particular class have been loosely grouped 
together into a class entitled special. In one case, a single connmand was categorized as 
a class itself. This was the find command. Several commands are also inherent to the 
Macintosh operating system. An example of this is the Aold command. It is equivalent 
to the Macintosh open command. 

The specific menu items and their functional definitions are as follows: 


e About... About... prompts the display of a window containing 
information about this prototype. 


e Desk Accessory This command calls the specified desk accessory to begin 


Operation (normiallv on-screen) for the user. 


e Group Create 
e Leave 


e Join 
e Group Send 


e Time Increment 


* Create This calls a procedure to create an action or utility directive. 

¢ Open Open, an operating system feature, is similar to the MIP’s 
hold command; it opens an existing file or document. 

e Save This operating system feature stores a named file. 

eSaveas« This operating svstem) feature stores a file after prompting for 
and receiving a filename from the user. 

e Close This operating svstem feature_closes an open file. The user is 
given a choice, if necessary, of saving changes or not. 

e Print This, operating system feature prints the open file at the 
Macintosh printer. 

e Send Send calls the send procedure to send a directive to the game. 

© Verify This command calls the verify procedure to ensure a directive 
is OK to send to the game. 

e Quit This operating system feature quits executing the application 


when selected. 


This command calls a procedure to create a group of 
directives. 


This command calls a procedure to take a directive out of a 
group. 


This command adds a directive to a group. 
This command sends a group of directives to the game. 
This command calls the IncGroupTime procedure to 


increment the execution time of the groups directives bv a 
certain amount. 


e Transmit Message This command allows a player.to prepare and send a message 
to another plaver or a group of players. 


e Receive Message This command allows a player to read his messages which are 
in the message queue. 


e Query The query command lets the player request a report from the 
ganie. 
¢ Graphics This command permits the plaver to make adjustments to his. 


graphics station during the course of the game. 


e Find This is a class of commands to find a specific group, directive, 
message or report which the player may have filed away. 


e Edit This class of commands is composed entirelv of operating 
Svstem commands which the player uses to edit text, etc. 


e ‘Trash’ This command permits the deletion of any file bv “dragging” 
that item to the trash can so the can 1s highlighted. 


These commands are incorporated into the Macintosh application by 
pre-coding them into a resource file. The resource file is read by the application 
program and the menu bar is constructed from the data contained there. Subsequently, 
any time a menu item 1s selected bv a plaver, the command is carried out by the 
program. An interesting feature of the menu itemis (and an entire menu list), 1s that 
they can be enabled or disabled as required during the course of execution of the 
program. Certain MIP commands cannot be performed while other actions are being 
performed by the plaver. The Macintosh program can handle these situations bv 
disabling the necessary commands in the menus. | 

The maintenance of the menu items must be done in three places, 
dependent upon the maintenance required. The resource file must be updated. the 
menu resource declaration in the program may need to be updated, and the source 
code to handle the menu event must reflect the changes made, as required. While this 
maintenance, on paper, seems elaborate, in practice it is relatively simple in most cases 
and will probably be rare as the addition or deletion of commands is not anticipated 
for the game itself. The source code may change as procedures called from the 
commands are added or deleted. 

(2) The Directives. The directives correlation to the prototype is that thev 
represent information to be manipulated. Manipulation of information is done via the 
window. Hence, each directive is displaved in a window. The directive attributes are 
displayed as information with predefined positions in the window. It is possible (and 
very probable) that they will not all be visible to the player. The plaver will have to 


scroll to view the attributes remaining out of view. 


The method of assigning values to an attribute is consistent and 
Straight forward. The player moves the cursor over an attribute and clicks the mouse 
button. This event activates a procedure which draws a dialog window. The contents of 
the dialog window are dependent upon the range or choice of values which can be 
assigned to that attribute as it’s value. Controls are used to make the assignments. Ifa 
number is needed, a control called a dial control is used with minimum and maximum 
values representing the range of values for that attribute. If a string is needed, such as 
a choice from a list, the list is displayed and each item has it’s own button control. The 
plaver selects the choice and that choice is assigned as the attribute value. 

The attribute values all represent some data base information stored in 
the individual plaver’s functional game file called the Player Initialization File (PIF). 
The PIF gets created by the game director during game preparation and represents the 
onlv correct and authorized set of information in any given game scenario. By. using 
the PIF, the range;choice of values can be determined’ based on the conditions of 
directive tvpe. units and their missions. unit resources, resource characteristics, and 
environmental data. It should be stressed that direct usage of the PIF data to populate 
“pop-up” windows or dialog windows is very efficient and not now being done in the 
current version. By reading the given PIF data into the dialog window, a value can be 
selected by the plaver. This is a significant change since the player no longer has to 
thumb through a sometimes large “plaver manual” to choose data and then correctly 
enter that data via the keyboard. The player can see that data in front of him, 
comprehend it quicklv, and “enter” the data in syntactically correct format: all bv 
clicking a button! 

This process is repeated many times during the course of a game and is 
in keeping with the refined data flow diagram design, Figure 3.2. I[t is natural. 
consistent, and permissive (for the most part) - three fundamentals in designing a visual 
interface such as this prototype for the Macintosh [Ref. 9: p. I-27]. In the following 
sections, the prototype is established as an application and the reader will be able to 


see how the aforementioned processes are implemented in an application such as the 
VETE: 
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B. THE PROTOTYPE - MACMIP 
1. The Prototype Abstraction 
The prototype, appropriately named MacMIP, was developed to provide the 
JCS managers another way to use and play JTLS. This prototype takes on a different 
appearance than most programs. Macintosh documentation stresses the point that 
Macintosh programs ltke MacMIP “don't quite look the way they do on other 
systems.” In Apple's words, “Everything you know is wrong.” [Ref. 9: pp. 1-4, 
4(Draft)] 
The reason is simply that event-driven programs behave differently and have a 
different structure. The first-level abstraction of MacMIP, Figure 3.4, shows the set-up 


of the program. 


Program MacMIP (Input, Output); 


Declarations 
Libraries; 
Constants; 
Types; 
Variables; 


Utility Functions and Procedures; 


Menu Driven Functions and Procedures; 
Event Driven Functions and Procedures; 
Initialization Functions and Procedures; 
Cleanup Functions and Procedures; 


Main Program. 





Figure 3.4 An Overview of MacMIIP’s Program Structure. 


In the material that follows, the first-level abstraction is refined tnto an 
abstraction level that is suitable for use as a guide for coding the prototype. The 


refined abstraction is a third-level abstraction and it’s elements are categorized and 
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their purpose defined. In fact, the third-level abstraction was used to code the 
prototype version used in the code comparison section of Chapter 2. The results of 
that code comparison demonstrate the desirability of continuing with the development 
of the prototype from an efficiency standpoint. A complete version of the third-level 
abstraction may be found in appendix A of this thesis. 

a. The Header and Declarations 

The Aeader is typical of any program. It simply invokes the program. The 
declarations section is again typical. It identifies operating system libraries used, 
establishes global variables by type, assigns values to constants (including the 
identification of resource files used), and formally sets up the data structures. 

The first significant difference from most programs is in the declaration of 
procedures. These application-specific procedures are categorically grouped together. 
The categories are utility, menu-driven, event-handling, initialization, and cleanup. 

(1) Ucility Functions and Procedures. The utility category is generally used 
as a catchall for the functions and procedures which do not belong to any other 


category. The utility functions and procedures and their purposes are as follows: 


e Directive This procedure draws a specific directive onto the 
screen. [t 1s called when a directive tvpe Naame em 

specified. | 
¢ Attribute Display This procedure highlights a directive attribute, 


calls a dialog box and displavs the attributes 
range‘choice of values for selection. returns the 
selected value, and assigns it to the attribute. It 1s 
activated by an event. 


e Assignments This is a set of piece oules which match .up to 
directive types. They, handle anomalies in the 
process of assigning directive attribute_values to 
particular fieldS of player orders. These are 
necessary since the MIP does not have a generic 
algorithm to do this. 


e Verify This is also a set of procedures which match up to 
directive types. Each verifies that the specific 
directive attributes are correct (outside of standard 
tvpe-checking) and are assigned to the appropriate 
field in the directive record. They are called Dvggme 
Send, Verify, Group Send, and Group Verify 
command procedures. 


¢ Retrieve Attribute Values This simply assigns attribute values to specific 
directive fields. 


¢ Player Order Assignment This procedure creates a player order record by 
assigning a directives attribute values into specific 
7 order fields in order to “match up” to the 
P’s equivalent of a player order record] ie 
handle the anomalies of anv specific directive, the 
procedure calls the necessarv — assigniient 
procedure. Plaver Order Assignment is called bv 
the Send. Group Send, Querv, and Transmit 
Message commands procedures. 
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e Mail a Player Order/ Message 


e Quick Order Display 


e Quick Attribute Display 


e List Control 


e Time Dial Control 


e Lat/Long Dial Control 
e Integer Dial Control 
e Real Dial Control 


e Lat/Long Conversion 


e Read From VAX 
e Write To VAX 


° PIF Update 


e Write The Status 


e Write the Player 


e CRR Get 


This concatenates the Deis lees Or message into 
a string Foe SESS sending it as an ASCII file 
Pomme ph melt is scalled by Player Order 
Assignment. 


This. procedure behaves similarly to Directive 
Displav. I[t is called by the Query and Graphics 
Adjust command procedures. 


This behaves sinularly to Attribute Display. 


This procedure takes a list, assigns each _ list 
member a control, and then draws the control into 
a dialog box. [tis called by numerous procedures. 


This procedure creates a dial control with range 
values commensurate with a-minimum = and 
maximum time, and draws the control into a 
dialog box. It returns a time value. 


This procedure creates a dial control. with 
minimum and maximum values, and draws it into 
a dialog box. It returns a latitude‘longitude point. 


This procedure creates a dial control. with 
nuninium and maximum values, and draws it into 
a dialog box. I[t returns an integer value. 


This procedure creates a dial control... with 
nuninium and maximum values, and draws it into 
a dialog box. It returns a real value. 


This function takes the = starting geographic 
point(SW) and the number of x,y hexés and 
deternunes the NE point of the playing surface. It 
then converts that point to lat/long coordinates for 
use as game boundaries. 


This procedure is used to communicate with the 
VAX by receiving. 


iinismpLocedute 1s used tO communicate to the 
VAX by writing to it. 


This is used to update a wide variety of the 
plaver’s database when MacMip is_ used 
interactively during game play. 


This procedure writes and updates that status 
dialog window. It 1s called by PIF Update. 


This procedure writes and updates the plaver 
dialog window. [t 1s called primarily during 
initialization. 


This is a set of procedures which get lists. times. 
geographic points, altitudes, etc. Fach procedure 
Nasmeamcavecmrcorrelation to the SIlPMsource code 
They are called by numerous higher-level 
procedures. 


(2) Menu-Driven Functions and Procedures. The menu-driven category 1s a 


collection of functions and procedures which are called as a result of a player selecting 


a menu item. These functions and procedures may in turn call a host of utilitv and 


ay 


Operating system functions and procedures. In general, these are called only from the 


Handle Menu procedure in response to an event. They are essentially used to carry out 


MIP commands which are not handled by the operating system. The menu-driven 


functions and procedures are: 


¢ Do 
¢ Desk Accessory 
° Create 


e Send 


e Verify 


e Group Create 


e Join 
e Leave 


e Group Send 


¢ Group Verify 


¢ Group Time Increment 


e Transmit Message 


e Receive Message 


© Query 


¢ Graphics Adjust 


e Find 


This procedure simplv draws a dialog box whose contents 
are information about MacMIP. It calls nothing. 


This procedure starts up a specified desk accessory for the 
player's use. 


This procedure issues the command to create a new 
directive. It calls a dialog window so the player may 
select a directive type. When the type is chosen, the 
Directive Display procedure 1s called. 


This procedure prepares actions directives for “mailing” 
and then places the orders into the mailboxes. It calls 
Verify, Plaver Order, and Mail a Player Order; Message. 


This procedure calls a directive specific verify procedure. 


This procedure establishes a group into which directives 
may be collected 


This procedure assigns an existing directive to a group. 
This procedure removes a specific directive from a group. 


This. procedure prepares a group. of directives for 
mailing’ to the CEP and then places them in ithe 
mailbox. It calls the Verify and Send procedures for each 
directive in the group. 


This procedure verifies that each directive in a group can 
be sent to, the game. It calls the Verify procedure for 
each directive in the group. 


This procedure increments the time_of execution for each 
directive in a group. It calls the CRR Get and the Time 
Dial Control procedures. 


This procedure allows the plaver to create and send_a text 
message to another player or players. It calls the Mail a 
Plaver Order; Message procedure. 


This procedure retrieves a, message from the plaver’s 
message queue and displays it on the screen so the player 
may view it. 


This procedure, similar to Create, requests reports from 
the game when MacMIP is in the interactive mode of 
Operation. It calls the Quick Order Display procedure. 


This procedure, also similar to Create, makes adjustments 
to the Hee § game graphics stations. It calls the Quick 
Order Display procedure. 


These, procedures. find any particular group, action 


directive, utility directive, message, or report that the 
player has filed away. 
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(3) Event-Driven Functions and Procedures. The event-driven procedures 
are those procedures which are performed as the result of the occurrence of some 
event. An event is normally a mouse click or a keystroke performed by the plaver. 
System events, such as the movement of the mouse, are also members of this categorv. 
Parameters of the events are examined to determine what occurred, where it occurred, 
and what is supposed to happen next. In turn, the event-driven procedures are 
invoked to handle the event. In a sense, these procedures are the “brains and nerve 
center’ behind the application's “bodily functions.” The procedures are: 

e Mouse This procedure identifies where the mouse was clicked and then 


calls another event to handle the task to be done as a result of the 
click and it’s location. 


e Keypress This procedure handles a keystroke event, including command 
keys. It may or may not explicitly call other event procedures. 

e Update This procedure handles updates to the three windows of MacM IP. 
It calls various procedures dependent upon what needs to be ° 
updated. 


e Handle Menu This procedure handles the event of a click in a menu item and 
calls the necessary menu-driven procedure including operating 
system procedures. 


e Cursor Adjust This procedure changes cursors based upon the cursor’s screen 
position as a result of mouse movement. 


¢ Handle Event This procedure: determines what event occurred and oversees the 
performance of the task to be done as a result of the event. 


(4) Initialization and Cleanup Procedures. The Initialization and cleanup 
procedures are the start and stop of the program. The -initialization procedure 
initializes everything in the program at the start of the program’s execution. I[t could 
be constructed as a combination of several procedures but here.it has been treated as a 
single giant procedure with calls to a few utility procedures. The cleanup procedure 1s 
invoked at the termination of the game. It simply erases the contents of the screen, 
logs off the VAX, and shuts down the Macintosh. The initialization and cleanup 
procedures are each invoked once during the execution of MacMIP. 

b. The Main Body of MacMIP 

The main body of MacMIP is a short, concise set of statements which are 
the “soul” of the Macintosh. After initialization, the program performs a repeating 
loop until told to quit. The loop first checks to see if any systems-defined tasks need 
to be done. If so, the Macintosh does them. The loop then checks to see if any events 
are in the event queue. If so, the system gets the first event of the highest priority 
class and performs the event-driven task. It then repeats the loop. When the system 1s 


told to quit, it invokes Cleanup and erases the screen. 


Be 


2. Background Issues of Prototype Design 
There were several issues which were (and still are) challenges to fully implementing 
MacMIP. The challenges primarily of interest here are the transition of an application 
(the MIP) from one computer system to another of a different format and the physical 
data link between the different systems. These challenges are not impassible but they 
do warrant special mention so the reader understands the task at hand. 

The task of implementing a prompt-based program, designed and written for a 
VAX minicomputer, into a graphics-oriented, event-driven operating system such as 
the Macintosh provides several challenges. First, it 1s not a trivial process since the 
Macintosh applications do not carry out a sequence of steps in a predetermined order. 
Rather, the Macintosh program is driven by user actions (such as clicking and typing) 
whose order of occurrence cannot be predicted. Thus, the SIMSCRIPT program 
cannot be running parallel to the Macintosh and expect the Macintosh to emulate a 
VAX terminal and still function in the visual interface mode. MacMIP must be 
programmed to account for the occurrence of events; the MIP’s prompt-based 
applications are not event-driven. 

Secondly, a thorough concept of graphics capabilities 1s necessary to 
effectively apply the visual interface to the MIP through the Macintosh operating 
system. Prompt-based applications such as the MIP generally use “menus” to display 
the prompts. Moving through the prompts is done sequentially due to the 
application’s rigid tree-like hierarchical structure; one prompt must be answered 
correctly before another one can be dealt with, especially if it resides on another level 
of the hierarchy. The code to set-up the prompts and move between them is usually 
rigidly structured as well. The Macintosh system does all this through the use of it’s 
graphics toolbox Quick Draw and the Resource Manager. Thus, any MIP source code 
dealing with the CRT display is totally unusable in MacMIP. To try to transfer it to 
the Macintosh would require too much source code just to negate those CRT 
instructions. Simply stated, reformatting is not trivial. 

The other issue of establishing a link to the VAN is also one which is possible 
but not trivial. Although the exact mechanics of establishing the link will not be dealt 
with here, it must be noted that the capability to link the Macintosh to the VAN has 
been demonstrated by the Jet Propulsion Laboratory, the Naval Postgraduate School’s 
C3 Laboratory, and the Warrior Preparation Center. among others. The reason for 


mentioning it is that the Macintosh runs only one application at a time. Therefore, the 
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instructions to link to the VAX on an interactive basis must be incorporated into 
MacMIP’s source code. It is also likely that the JTLS Executive Level Program must 
know that a particular link and game mailbox is a Macintosh and not a VAX VT-100 
terminal. With these issues in mind, the general format and design of the prototype 


can be implemented. 


C. CREATING DIRECTIVES WITH MACMIP 

The use of MacMIP to create the AWACS directive will result in the same 
directive being created as examined earlier in this thesis. The method of creating it 
now has a new look. To appreciate this prototvpe, the reader is invited to step 
through the process again. 

The process begins with the player. With the mouse at his fingertips, the player 
moves the cursor around on the screen. As the cursor moves across the menu bar, the 
player positions the cursor over one of the menu titles and presses the mouse button. 
While holding down the mouse button, the player “pulls down” a list of menu items bv 
dragging the mouse, Figure 3.5. As the cursor passes over the pulled-down menu 
items, the plaver releases the mouse button while the cursor is positioned over the 
create command. This constitutes an event so the Macintosh software determines what 
event occurred and where, and, having recognized the event, handles it. In doing so, 
the menu-driven procedure Create is invoked. 

The issuance of a command starts the ball rolling. First, MacMip reads a 
resource file to get a dialog window, gets a list of directives the player can create. 
invokes list control, and finally draws all of them onto the screen, Figure 3.6. The 
player can quickly and easilv see what his options are. The player can select a specific 
directive type or cancel the create and quit. If the player cancels, nothing happens 
except the command is canceled. Actually, the player can quit at any time without 
penalty; the main window is simply erased. If the plaver selects a directive type such as 
AWACS, Directive Display is invoked. 

When Directive Display is invoked, MacMIP reads a resource file which places 
control buttons in a pre-determined order, assigns an attribute name to each button, 
and draws the AWACS attributes onto the contents region of the main window. As 
the player clicks on any attribute, the attribute control is enabled and invokes the 


attribute display procedure. 
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Figure 3.5 The MacMIP Menu Bar with Menu Items. 


Now MacMIP determines the type of attributes (squadron, for exainple) clicked 
on and determines the range of values or choices eligible to be assigned as the 
attribute's value. In the case of squadron, this would be a list of air squadrons with an 
AWACS nussion. MacMIP then draws a dialog box, with the appropriate controls 
and information, Figure 3.7, and waits for.the user to select a value. Once this 1s done, 
MacMIP assigns the value to the attribute. For example, 73 AWACS SQ would be 
selected as the value of the attribute squadron. The dialog box is erased and the 
portion of the directive covered bv the dialog box is redrawn. 

When the player selects an attribute which is a utility directive, such as Air 
Route, the plaver has the option of referencing the air route ID or creating the air 
route directive. If the first option is selected, MacMIP behaves as normally expected 
for an attribute and displays a list of choices. One choice is an empty textedit box so 
the player can reference a vet to be created Air Route. If the plaver chooses the latter 
option, MacMIP remembers the AWACS window, invokes Directive Display again, 
given a type of “air route”, and draws a new window over the AWACS window. 
NOTE: This is similar to the OVERMIP feature of the MIP but this is not restricted 
to just three windows or limited performance of commands. With a new window, 


MacMIP can perform any command allowed for an active window and it’s function, 
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Figure 3.6 The AWACS Directive as drawn by MacMIP. 


regardless of the number of windows. Practical limitations of approximately 12 
windows are dictated by Macintosh operating software but the only physical limitation 
is with memorv space on the system. Now Air Route is handled just like any other 
directive. When the plaver is done with Air Route, he simply saves it. ‘The Air Route 
Window is erased while it’s information is stored somewhere in memory. The player is 
now returned to the AWACS directive window and continues to process information in 
it. 

This process continues on for the plaver at his will. Ile would never have to hold 
a printout on his lap to find data. It would always be available to him on his 
computer “desktop.” The player would control the data yet quickly move between 
different tasks of varving modes as he deemed necessary and never lose any 


“document.” It would always be somewhere on his desktop! 
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Figure 3.7. The Directive with the Dialog Box. 


D. THE FUTURE UTILIZATION OF THE PROTOTYPE 
1. Technical Aspects of Prototype Utilization 

A brief review of the methodology used is in order to shape the prototype’s 
future. The methodology used to develop this prototype was simple and 
straightforward. The ultimate goal was established as the application of the Model 
Interface Program onto the Macintosh operating system. The process of doing this 
can be mapped out in steps. First, understand the MIP operations, t.e. what it does. 
Then understand the SIMSCRIPT program language and how it operates on the VAX 
nunicomputer. A collateral task is to understand the Macintosh operating system, it’s 
capabilities, and the programs it uses well. Then the task is to understand the design 
and structure of the MIP and correlate it into a design using the visual interface. Once 
this is done, the next phase is to translate the design concepts into a code-like format 


so the prototvpe takes on a realistic look. This is the point where the prototype 


development ts now. 
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In getting the prototype to this point, much of the original source code was 
examined to determine how the MIP works. In doing so, it became evident that much 
of the logic and algorithms used would be effective in MacMIP. The reason is that the 
“behind the screen” manipulation of information by the MIP is fairly effective so there 
is no reason to re-invent the wheel. It is the format and presentation of the data which 
sparked the idea for the prototype in the first place. With this in mind, it becomes self- 
serving to use that code in this prototype. This is evident by the references made to 
specific MIP modules in the MacMIP psuedocode. An underlying premise is that the 
development and production of WacMIP would be considerably shortened compared 
to a full re-design. 

There were numerous ideas borne out of this development with regards to 
future prototype development. One idea mentioned earlier was that of placing 
individual directives into resource files. This would speed-up Macintosh operations 
and provide a cleaner, sleeker display. The better the graphics, the better the visual 
interface. The MIP currently reads in all commands and all of the various directives. 
queries, adjustments, etc., from a database. The database is not expected to change 
significantly over time so maintenance and currency should not be significantly 
impacted upon. While the MIP currently reads the data in based upon player function, 
the same school of thought could apply to MacMIP. The answer is to have a separate 
diskette per function and simply load that function’s diskette into the Macintosh when 
that function is used. One advantage to this is to effectively utilize memory space. 
Another advantage, for game management, will be addressed shortly. 

A second idea, which follows the lead of the first, is to place each plaver’s PIF 
On a separate diskette as well. The PIF is developed by the CEP upon initialization of 
a scenario database. Since the PIF doesn’t change unless the scenario does, it is 
feasible to pre-load the PIF for each scenario used. A separate diskette per function 
per scenario would allow great flexibility in the use of the prototype. An extension of 
this advantage would be that only the function affected by a change to a scenario 
would have to be updated. This idea would also save machine memory space, a 
concept which closely relates to the way JTLS already reduces CPU input/output bv 
using video disc digital graphics. 

Another feature of the MIP which has not been addressed in the prototype is 
the svstem capability for the expert player. Presently the expert player can tvpe all the 


directive data into one string in a predetermined order (this is called stacking), enter it, 
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and have a complete directive. This capability is a natural for a prompt-based 
application. However, with the Macintosh and the visual interface format in use, the 
stacking capability is a diametrical opposite. As such, it was not designed into the 
prototvpe. To fully realize the potential of MacMIP, this capability should be 
incorporated into MacMIP as a text edit faculty. 

Finally, an aspect of development to be considered is a total re-design of the 
MIP. The key issue with the MIP is it’s ability to communicate the plaver’s intentions 
to the game. This is done by passing ASCII data between the two programs. 
Therefore, the MIP could manipulate it’s data in many different ways just as long as 
the file passed was in proper order and format. Consider first that SIMSCRIPT is a 
modeling programming language. The MIP per se models nothing. It is written in 
SIMSCRIPT to be consistent with the other JTLS programs. Instead of being a model 
which generates data, the MIP simply manipulates data. Since the MIP manipulates 
data, consider the possibility that there is a more efficient method of manipulating that 
data. That method is a data base management svstem (DBMS). Several excellent 
svstems exist which were designed expressly for the Macintosh. One of these or a 
specially designed system might do a better job of dynamically manipulating the large 
amounts of data used in JTLS. If a decision was made to use a very capable 
workstation, such as the SUN or IRIS workstations, for a future generation JTLS 
input device, a DBMS system coupled with a windowing and resident color graphics 
environment becomes a very attractive system option. A single workstation could 
easily function as a graphics station and MIP substitute. 

2. Managerial Aspects of Prototype Utilization 

JTLS was originally developed with military training in mind. As events have 
transpired that original premise has been overcome. The issue of computer siniulations 
used as planning aids has come to the forefront. With the proliferation of the desktop 
microcomputer, prototypes like MacMIP take on increased importance. One 
important reason is found in the methods used by planners to test various strategies 
and tactics. A planner develops a strategy and then must test it for feasibilitv. If the 
planner could prepare in advance all of the missions expected to be used for a given 
strategy, then the planner could do all that work in his office where all his references, 
working papers, etc., are located. When the planner tests his plan, it is done in the 
computer laboratory. Using a portable system of diskettes from a desktop computer. 


the directives could be transported (so could the Macintosh for that matter) to the lab 
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and loaded into the game. This would save a considerable amount of time for the 
planner as the game could be played faster, more repetitions could be run with more 
variations of game parameters, and a greater spectrum of outcomes realized for 
analysis of plan effectiveness. 

A reason of secondary importance is found in the basic premise of the visual 
interface. It is geared toward the casual user. The military planner is not a computer 
systems expert by trade. The planner’s expertise can range from the novice category to 
the expert. By designing and using a system like the Macintosh, with it’s visual 
interface, the needs of all users can be met. One can assume that even the expert is 
not likely to use JTLS on an everyday basis over an extended period of time. With so 
much diversity in.a planner’s work, it would be easy for even the expert JTLS 
gamesman to lose his grasp of the game's nuances. With a continual change of 
scenarios, the data used by the plaver would change and further compound the 
problem of maintaining game skills. The prototype would quickly return the planner 
to a high level of effectiveness in game skills, or quickly train the planner new to JTLS, 
due to it’s graphical orientation and it’s ease of use. [f correctly designed it will also 


reduce input error rates at all stages of training of the player-analyst or plaver-planner. 
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IV. CONCLUSIONS 


The original purpose of this thesis was to examine enhancement of plaver inputs 
to JTLS through computer graphics techniques. The overall result of the examination 
is that a graphical application of the game is a very efficient and a desirable method to 
effect player inputs. This result is supported by positive use of human visual 
information transfer, the ability of computer software such as window management 
systems to convey this information, and the capabilities of hardware such as the 
Macintosh operating system. Symbolic association has long been recognized as a 
positive method of communication. The use of computer graphics is a logical 
extension of that school of thought and has found an application in window 
management systems. The windowing capabilities in the Macintosh, when compared 
to the prompt-based VAX, show a distinct advantage in providing ease of plaver input 
and, at the same time, indicates a potential savings in the amount of code necessary to 
perform. the same operations on the VAX. The results of this examination fully 
supported the development of the prototype. 

The prototype design shows how to improve the current methods of effecting 
player inputs. The design of the prototype incorporates the advantages mentioned 
above. The design identifies the areas of the Model Interface Program most in need of 
enhancement and then breaks down the functions of each area by correlating them into 
visual (graphical) objects. The design also identifies a very capable language (Pascal) 
for coding such a prototype and correlates the original SIMSCRIPT source code (data 
structures, logic, and language constructs) to It. 

This road map of design leads directly to the pseudocode abstractions. These 
abstractions show that the coding of the prototype is possible and goes so far as to lay 
out the programs skeletal structure. The categorization of MIP functions allows for 
explicit definitions and routines of MacMIP which in turn perform the MIP’s 
functions. The road map allows for a total rewrite of the MIP. The next step to be 
taken in the design process is to actually begin coding. Although a total rewrite is a 
large undertaking, and bevond the scope of this thesis, it is the most efficient and 


economical method of implementing the graphical enhancements. 
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In the case of the Macintosh, the powerful capabilities of the microcomputer 
would be lost if it was coded to simply emulate a VAX VT-100 terminal. Then the 
Macintosh graphics would not provide any true enhancements to the player input 
mechanism. Also, while the psuedocode was written with the Macintosh in mind, it is 
purported to be general enough to provide decisionmakers a basis for which to apply 
the MIP functions to other graphics-oriented window management computer 
workstations. Indeed, the proliferation of low-cost microcomputers with graphics 
capabilities give the prototype increased credibility. 

In summary, the prototype can be a valuable tool to ITLS managers in the near 
future. The design is generic enough to apply to any window management system but 
is ready to be coded for the Macintosh. The best of the original source code has been 
applied to the prototype to aid quick implementation. It’s use in a desktop, office 
environment will provide the manager greater flexibility in utilizing JTLS to it’s full 


capability and worth. 
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APPENDIX 
MACMIP: THIRD-LEVEL ABSTRACTION 


Program MacMIP (Input,Output) 


JBC BREE RUHR DECLARATIONS Cof the globals ) 226326363 36363¢3¢ 316362636 2696 HEHE HEHE IEHEIEEHE 


*¥*% Operating System Functions *** 


(SR) ¥range checking, on/off 

(SI ) xinput/output error checking, on/off 
($I <filename>) *inclusion of file(s) 

(sp ) *xbundle bit, on/off 

($R <filename>.Rsrc) *xidentify resource files used 

($T APPLDMO1) *xset application identification 
(sux ) *xauto-link to runtime units», on/off 
(ss ) xuse of segmented code, on/off 

($S <segment name>) ¥name of segmented code used 


%*¥% Macintosh Interface Units 


USES 

PasInOut *xImplements the standard Pascal input/output (1/0) routines. 

MemTypes *xDefines special Macintosh data types and must be in any Mac-style 
application. 

* QuickDraw *The Macintosh graphics package. ‘ 

SCSIIntf *Provides access to interface port and permits communications with 
the port. 

OSIntf *The operating systems interface which performs lowest level basic 
tasks. : 

TooIntf *¥Implements the user interface features of windows», menus» 


controls, dialog boxes, text editing commands, etc., and must be 
in any Mac-style application. 


PackIntf *The interface to packages of data structures and routines which 
are stored as resources. 


MacPrint *Provides access to Macintosh printing manager. 
(*%* NOT USED: Any of the following may actually be needed when MacMIP is actually coded; 


however, they do not appear necessary at this time: PasControl, PasPrinter, SANE, 
FixMath, Graf3d, AppleTalk, SpeechIntf. xx) 


HHH HHH HHH HHH HEHEHE HHH HHHHHHR Constants, Types, and Variables 2363323333232 3 HHI HEHEHE HEE IEN 


CONSTANTS 
Menu List Count = 6 *total number of menus 
Apple Menu = xx *xthe resource 
File Menu =xx *ID unique 
Group File Menu =xx *to each 
Edit Menu *¥specific 
Special Menu = xx ¥menu file 


Find Menu =xx 


AM = x *index 
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TYPE 


FM = x xinto 
GM = x ¥menu list 
EM = x *for 
SM = x ¥each 
FDM = x *menu 
Main Window ID = xxxx *xthe resourcelD 
Status Window ID = xxxx *xunNique to each 
Player Window ID = xxxx ¥specific 
Attribute Window ID = xxxx ¥xwindow used 
Buffer Size = xxx *for disk I/0 
Buffer Count = xxx *for disk I/O 
Player File = RECORD of 
PF Concat.F : char 
PF Suffix : char 
PF Unit : integer 
Player = RECORD of 
PL side char 
PL side number integer 
PL function char 
PL function no. integer 
PL receives input integer 
PL graphics station integer 
Mailbox = RECORD of 
MBX logical name : char 
MBX size : integer 
MBX channel : integer 
Message = RECORD of 
MSG status integer 
MSG text : char 
Unit = RECORD of 
UT Pointer integer 
UT long name >: string 
UT short name : string 
UT type integer 
UT AS aircraft available : integer 
UT AS aircraft type : integer 
UT side : integer 
Directive = RECORD of 
DIR ID char 
DIR unit 1 char 
DIR unit 2 char 
DIR unit 3 char 
DIR unit @ char 
DIR target 1 char 
DIR target 2 char 
DIR lat 1 double extended 
DIR lat 1 text ; char 
DIR lon 1 ; double extended 
DIR lon 1 text : char 
DIR lat 2 double extended 
DIR lat 2 text char 
DIR lon 2 double extended 
DIR lon 2 text : char 
DIR time ; double extended 
DIR time text : char 
DIR duration double extended 
DIR duration text char 
DIR generic 1 text char 
DIR generic 2 text char 
DIR generic 3 text char 


el 


DIR generic 1 integer : integer 

DIR generic 2 integer >: integer 

DIR generic 3 integer : integer 

DIR generic 4 integer : integer 

DIR generic 1 double : double extended 

DIR generic 2 double : double extended 

DIR generic 3 double ; double extended 

DIR generic 4 double : double extended 

DIR generic 1 Ipointer integer 

DIR generic 1 Tpointer integer 

DIR generic 1 Dpointer : integer 
Attribute Prototype = RECORD of 

AP prompt string 

AP field code string 

AP arguments string string 

AP number integer 
Directive Prototype = RECORD of 

DP long name string 

DP short name : string 

DP meaning : integer 

DP CEP class : ; integer 

DP assignment routine : integer 

DP verify routine : integer 

DP attribute prototype array (1 to 12) of RECORD 

DP number attributes integer 
Quick Attribute Prototype = RECORD of 

QAP prompt : string 

QAP create routine integer 

QAP arguments string string ° 

QAP conversion type integer 

QAP PO word : integer 

QAP all flag : integer 
Quick Order Prototype = RECORD of 

QOP context integer 

QOP full name string 

QOP numeric name string 

QOP CEP class integer 

QOP CEP specific type : integer 

QOP CEP number > integer 

QOP message : integer 

QOPQAP : array (1 to 4) of RECORD 
Air Weapon = RECORD of 

AW name : string 

AW X air ground >: real 

AW X weapon weight real 

AW X supply category real 

AW X night factor real 

AW X weather factor real 

AW X weapon color : real 

AW X weapon effects >: real 

AW X long range : real 

AW X precision guided : real 

AW X weapon speed real 
Aircraft = RECORD of 

AC name string 

AC X range real 

AC X day night real 

AC X crew time real 

AC X fuel real 

AC X weather factor real 

AC X runway required real 

AC X type >; real 

AC X wet weight : real 


AC X dry weight : real 

AW X EC factor : real 

AC X max altitude >: real 

AC X speed >; real 

AC X load time >: real 

AC X aircraft side : real 

AC X damage ratio : real 

AC X refuel >; real 

AC X spare : real 

AC X enemy detection >: real 

AC X engage fuel >: real 

AW X AI range >; real 
Supply Side, Supply Category = RECORD of 

SS name : string 

SS units : string 

SS multiplier : real 
Function = RECORD of FN name : = string 
Unit Type = RECORD of UTP TEXT : string 
Target Type = RECORD of TTP TEXT : string 
Emitter Suite = RECORD of ES name : string 
Word Indicator = RECORD of Word Integer : integer 
Sensor Package = RECORD of SP name : string 

SP number : integer 

CRRGet Routine = RECORD of Create Routine : integer 
Associated Directive = RECORD of AD dir ID : _ string 
Month = RECORD of 

Mth name -: string 

Mth length : integer 
Order Record = RECORD of 

OR time text , 3: string 

OR time >: real 

OR DP meaning : integer 

OR status : string 

OR Message >: string 

Associated Directive : RECORD 
Player Order’ = RECORD of 

PO class : integer 

PO specific type : integer 

PO unit : integer 

PO time effective >: real 

PO word 1 integer : integer 

PO word 2 integer : integer 

PO word 3 integer : integer 

PO word ¢ integer : Integer 

PO word 5 integer : integer 

PO array 1 pointer : integer 

PO array 2 pointer : integer 

PO array 3 pointer : integer 

PO array % pointer : integer 

PO array 5 pointer : integer 

PO word 1 real : double extended 

PO word 2 real : double extended 

PO word 3 real : double extended 

PO word 4 real : double extended 

PO word 5 real : double extended 

PO word 1 text : char 

PO word 2 text : char 
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Target = RECORD of 


TR pointer : integer 
TR number : string 
TR name : string 
TR type : integer 


VARIABLES 
Date Stamp, 
Status Line, 
Special Status, 
Player Line, 
User ID, 
Simulation Time Text, 
Scenario Name» 
Game Classification, 
Supply Field : chars 


AMP Flag,» 

Starting Day» 
Starting Month, 
Starting Year, 

No of Login Builds, 
Air Refuel Index, 
Supply Width, 
Supply Precision, 
Sun Status» 

Number X Hexes» 
Number Y Hexes > integers 


Simulation Time, 

Supply Minimum, 

Supply Maximum, 

Lat Hex One,» 

Long Hex One - 

Lat East 

Lat West 

Lang North . 

Long South : reals 


HEHE HEIEIE HEHEHE HEHEHE HEHEHE EHEC HEHEHE INHNM Utility Functions and Procedures 33363 333 III HH HEHE HE HIE HIE IE HEHE 


*These subroutines may or may not be representative of original MIP logic. If there is a 
correlation, then the MIP subroutine ID will be annotated within brackets to guide the 
programmer to that original source code. 


Directive Displays 


*This display is called from a resource file, develops a specific directive's display, and 
draws it into the main window. * 


Given a DP meaning; 
Read the resource file for the generic directive displays 
For each static item do} 
index I from 1 to 123 
Get attribute prototype of DP meaning; 
index J from 1 to N3 *¥N is the number of attributes 


for the given DP meaning. 
For I = J do} 


Change the static text to represent AP prompt and AP field code} 
For each I > N do3 ; 


Hide the static item so it can't be seen or enabled; 
Now draw the display into the main windows 


End Directive Display; 


Attribute Display; 
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*This is activated when a directive attribute is highlighted. It determines what type of 
attribute it is, gets the appropriate type of control, gets a range/choice of eligible 
values, and assigns each of them a control. It then draws the control into a dialog box 
onto the screen. When a particular control is activated, that value is assigned to the 
attribute variable.* 


Given AP{J) with a DP Meaning; 
Read a resource file for the dialog box;s 
For AP create routine (J) do CRRGet; [I100 ] 
Case of (1 to 25)3 *get the appropriate create control routine 
Draw the dialog box with the eligible values and their controls} 
For activated dialog box assign a value to word; 
*Of Word Integer of AP(J}. 


End Attribute Display;3 


Assignment} 


*This procedure handles the anomalies found when assigning directive-specific attributes 
to the Player Order fields. All AIR directives (DP meaning 301 to 399) use assignment 300 
as well as their own specific assignments. * 


Given a DP meaning; 
Invoke assignment.DP meanings [A101 to A104, A106, A123, A200 to A227, A300, A306, 
A312 to A314, AGOl to AGO7, A501 to A503, A800] 


End Assignment; 


Verify3 


*This procedure verifies that certain directive-specific assignments were made before 
allowing the Player Order to be sent to tha CEP. The first part of the assignment checks 
for the existence of a referenced utility directive and the remainder invokes’ the 
directive-specific verifications.* 


The send flag is not set} 
Given a DP meanings 
For each utility directive in directive} 
Determine it exists: 
No : Draw an error dialog box to alert the players 
Yes : Then go on3 
If utility directive is weapon load; 
Determine weight of load for Aircraft is OK: 
No : Draw an error dialog box to alert the players 
Yes : Then go on} 
Invoke verify.DP meanings [V101, V10¢, V106, V123, V200, V202 to V209, V211, V214, 
V217, V218, V222, V225, V300, V306,5 V312, V401 to V407, 
vV501, Vv800] 


End Verify; 


Retrieve Directive Attributes; [U019] 


*This procedure assigns a blank string to attributes with “Null Entry" as values. This 
permits acceptable formatting of the Player Order. * 


Given word integers 
Case of that words 


End Retrieve Directive Attributes} 


Player Order Assignment; [A000] 


TS 


*This procedure assigns directive common attributes to specified Player Order fields. 
Given a DP meaning it then invokes that directives specified assignment.* 


Given Directive with DP meaning; 

PO class = DP CEP class} 

PO specific type = DP meaning; 

PO time effective = DIR time}; 

PO word 2 text = DIR ID3 

If DIR unit 1 name * Null Entrys 
For UT short name = DIR unit 1 name3 
Let PO unit = UT pointers 

Invoke Assignment.DP meaning; 


End Player Order Assignment} 


Mail the Player Order/Messages [U018] 


*This procedure concatenates the Player Order into one string of char for purposes of 
sending it to the CEP. After the Player Order is made, it is read to port. This is done 
by invoking Write To VAX. Then the Player Order is reset to 0.* 


Given a Player Order; 
For directive with DP meaning = 1013 
Increment No of Login Builds}; 
Convert all integer and real values to character} 
Concatenate all Player Order fields into one strings *This is Known as a message. 
Determine that the message will fit into the mailbox: 
No : draw an error dialog box to alert the players 
Yes : If message is directive thens 
OR time text = Simulation time text} 
OR DP meaning = DP meanings 
OR unit = DIR unit 1 names 
AD DIR ID = DIR ID} 
File Order Records 
If mode is “on-line" put the Player Order message into the mailbox; 
Reset Player Order = 03 *For the next time. 


End Mail the Player Order/Message}3 


Quick Order Display3 
*This procedure is similar to Directive Display but on a smaller scale.* 


Given a QOP contexts 
Read the resource file for the generic display; 
For each static text item do} 
: Index I = 1 to 63 
Get Quick Attribute Prototype for QOP context; 
Index J = 1 to N3 *N is the number of attributes. 
For I = J do3 
Change the static text to represent QAP prompt} 
For I > N do3 
Hide the static text so it can't be seen or enabled; 
Now draw the display into the main windows 


End Quick Order Display; 


Quick Attribute Display; 
*This is similar to Attribute Display but on a smaller scale.* 


Given QAP(J) with QOP context} 
Read the resource file for the dialog box; 
For QAP Create Routine (J) do CRRGet: 
Case of (1 to 25) : Do Create Control3 *As appropriate. 
Draw dialog box with eligible values and controls; 
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End Quick Attribute Prototypes 


List Control; 


*This procedure develops and draw a dialog box with controls for each item in the list. 
It returns a value of char.* 


Given N number of items in List; 
If List is multiple entry then 

Assign a check box for each item; 
Else 

Assign a radio button for each item; 
Map item to graphics positions 
Draw the dialog box in the main windows 


End List Controls 


Time Dial Control; 


*This procedure develops and draws a dialog box with a scroll dial to return a value of 
time. Minimum time always = 1 minute.* 

Given maximum day value; . 

Given game minimum times *If time is for "Duration" then game minimum time = 0 
since the value needed is a block of time for incre- 
mental purposes. 

Determine minimum and maximum values for the control: 

Minimum value = game minimum time + 13 
Maximum value = game maximum time + maximum gavae 
Draw a scroll dial using minimum/maximum values; 
Current value is minimum value; 
Format is 2 places for days, 2 places for hours, 2 places for minutes; 
Return a time values} *Usually is converted to a real number in terms of days. 


End Time Dial Control; 


Lat/Long Dial Controls 


*This procedure develops and draw a dial control onto the dialog box to return geographic 
points. Only degree fields must have values. Direction value in text converts for 
real values of lat/long. 


Given a minimum and maximum values *Usually the game boundaries. 
Determine the number N of points to be made; 
Draw a scroll dial with minimum/maximum valuess 
Current value is minimum values 
Format is 3 places degrees, 2 places minutes, 2 places seconds, and 1 place 
direction; *For lat the first place has a value of 0. 
For N points dos 
Enter a latitudes 
Enter a longitudes 
Convert all points to real values; 


End Lat/Long Dial Control; 


Integer Dial Controls 


*This procedure develops and draws a dial control in a dialog box and returns an integer 
value.* 


Given a minimum and a maximum value; 

Draw a scroll dial with minimum/maximum values; 
Current value is minimum values 
Format is 5 places; 

Return an integer value; 
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End Integer Dial Control; 
Real Dial Control} 


*This develops and draws a dial control with minimum and maximum values and returns a real 
value. 


Given minimum and maximum values} 

Current value = minimum value} 

Format is 9 places with 5 decimal places; 
Draw a scroll dial with minimum and maximum values} 
Return a real values 


End Real Dial Control; 


Lat/Long Conversion;[U013, U014, U015, U016] 


*xThis develops the game surface boundaries in terms of latitude/longitude for use as dial 
ranges. * 


Given Lat Hex One, Lon Hex One, Number Y Hexes, and Number X Hexes}3 

Convert to Lat Hex X, Lon Hex Y}3 

Convert hexes to coordinates; - 
Results in Latitude East/West and Longitude North/South; 


End Lat/Lon Conversions} 


Read From VAX} : 


*This uses the RS-232 port as a device and reads an ASCII file from the device if 
something is in the buffer. The buffer must be checked periodically. 


End Read From VAX} 


Write To VAX; 


*This writes an ASCII file to the RS-232 port when called to do so by the Macintosh. It 
contains protocol information for the VAX and Macintosh to communicate. * 


End Write To VAX} 


PIF Update; [CEP Process] 


*xThis reads a message from the CEP, determines it's type and subtype, and take the 
necessary actions depending upon the type.* 


Read From VAX} 
For message type case of 
{1) Message : do 
increment queue by 13 
file message in queue} 
Write The Status given queue} 


{2) Time : do Write The Status given times 

{5) Interrupt pending : do Write The Status given special status; 

{6) Target : do a new target record; 

(7) Game speed : do Write The Status given game speed; 

(8) Stop password : change the password; 

(9) PIF updates : case of subtype : 
(1) Aircraft available : find the unit, change it's number; 
{2) Cargo trucks available : find the unit, change it's number; 
{3) Tanker trucks available : Find the unit, change it's numbers} 
(4) Aircraft characteristics : change the aircraft's records 

[U028] 


{5) Air weapon characteristics : change the air weapon's records 
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(U029] 


(6) Personnel weight : change the personnel logistics load record; 
(7) Aircraft name : change the aircraft's name} 
(8) Air weapon name : change the air weapon's name3 
(9) Sensor package name : change the sensor package's name} 
(10) Emitter package name : change the emitter package's name} 
(11) Supply category : change a supply category's record; 

(10) Sunrise-sunset : do Write The Status given sunstatus}3 


End PIF Updates 


Write The Status 
*¥This procedure develops and draws the status window and the information it contains.* 
Given queue, game speed, starting time and date, and special status}; 
Read a resource file to get a dialog windows 
For each static text, change the static text to the necessary values 
Draw the dialog box} 


End Write The Status} ° 


Write The Players 

*This procedure develops and draw the player window and the information it contains. * 
Given classification, player function, scenario name} 
Read a resource file to get a dialog window; 
For each static text, change the static text to the necessary value} 


Draw the dialog box} 


End Write The Player} 


CRRGet Procedures} 


*These procedures get certain information for attributes and directives. Each gets some 
specific information, thus they are listed along with their MIP module number. * 


Get an ID [U101] 


Get a Duration [U110] 

Get a Lat and Long ([U111] 

Get a New Target Name [U106] 

Get a New Target Number [U105] 
Get a Real Number [U114] 

Get a Route [U115] 

Get Additional Route Info [U026] 
Get a Runway Name [(U124] 

Get a Sensor List [U118] 

Get a Supply Changes List ([U122] 
Get a Supply Load [U116] 

Get a Target Name [U104] 

Get a Target Types List [U123] 
Get a Targets List [U113] 

Get a Time [U109] 

Get a Unit Name [U103] 

Get a Units List [U112] 

Get a Weapon Load ([U117] 


Get an Emitter List [U119] 
Get an Integer [U112] 
End CRRGet}3 
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*¥% Apple Menu Functions and Procedures 
Do Abouts 
*This procedure simply tells the user some information about MacMIP.* 


Read the information needed from resource filess 
Put together a string of parameter texts 

Get the dialog box and put it up} 

When it has been read, get rid of its 


End Do Abouts 


Do Desk Accessory} 
*This gets the selected desk accessory and starts it up.* 


Save a port for the desk accessorys 
Get the desk accessory name} 
Start the desk accessory} 


End Do Desk Accessory} 


***% File Menu Functions and Procedures *** 
Create} [Command({1) of C000] 
*This procedure determines what directive to build and does it.* 


Determine the directive type (Action or Utility); [06001] 
For type selected put up a dialog window with list of OP meanings} 
Given list do List Control}; 
Return the selected value = DP meanings 
Dispose of that windows 
Given DP Meaning do Display procedure; [C002] 
For each attribute highlighted do Attribute Display procedures *Get a value 
for the 
attribute. 
Do Retrieve Directive Attributes procedures 


End Creates 


Send; [Command({101) of C000] 


*Sends only action directives, not previously sent, to CEP. The file sent must be open in 
window. * 


Given DP meaning do Verify procedures 
Check verify flag case of: 
Not set : verify and set flag} 
Set : go ons 
Do Player Order Assignment; 
Mail the Player Order/Message} 


End Sends 


Do Verify; [Command(106) of C000] 
Check verify flag case of : 
Set : Tell player that directive is OK} 
Not set : For OP meaning do Verify procedure; 


End Verify; 
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x**% Group File Menu Functions and Procedures *x* 
Group Create; [Command(51) of C000] 
*This procedure creates a group of directives.* 
Get a unique ID for the group; 
List the action directives which do not already belong to a group; [C103] 
Do List Control; 
Return a value; 


Place the selected directive in the group; 


End Group Creates 


Joins [Command(109) of C000] 
*This procedure adds a directive to a group.* 
Given an open directive put it into an existing groups [C103] 


End Joins 


Leave} [Command( 110) of C000] 


*This procedure removes a directive from a group. *x* 
Given an open group and a list of it's directives; [C104] 
Do List Control 
Returned value is selected directive; 
Remove selected directive from groups *It will stand alone. 


End Leave} 


Group Send; [Command!( 54) of C000] 
*This procedure sends a group to the CEP by sending a directive at a time.* 
Check group to ensure Directives with DP meanings 310 and 800 aren't in the group at 
the same time; {coo9] ‘ 
Yes :remove one of them; 
No : then for each DP meaning do Verify; 
When all are verified do for each : Sends *One at a time. 


End Group Send; 


Group Verify; [Command(58) of C000] 
*This procedure verifies a group of directives.* 
Do Verify procedure for each directive in groups; [C009] 
Except if DP meaning = 8003; *Verification not done on Air Mission Package. 


Set verified flag} 


End Group Verify; 


Group Time Increments [Command(59) of C000] 
*This procedure creates a block of time to add to a group.* 


Check group directives for DIR Time Text + 0 and DIR Time Text 4+ Null Entry; 
[C010] 
If so for that directivels) increment DIR Time and DIR Time Text; 
Do Time Dial Control; 
Return a block of time; 
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End Group Time Increment} 
*¥% Special Menu Functions and Procedures *** 


Transmit Messages [Command(5) of C000] 
*This procedure allows the player to create a text message to send to another player.* 
Select Player(s) to send message tos [C010] 
Includes “all”, "all Blue", “all Red's 
From is entered as Player's function and sides 
Enter message as a text strings 
Enter "//" To indicate the end of the messages 
Invoke Player Order Assignments 
InvoKe Mail the Player Order/Message}3 
Do as a repeating loop to place into each mailbox as required; 


End Transmit Message} 


Receive a Message} [Command(14) of C000] 


*This procedure is invoked only when their is a CEP message in the queue. It pulls out 
the CEP message on a FIFO basis for the player to read or print.* 


Read message file for first messages [C006] 
Draw that message to the main windows 


End Receive a Message}$ 


Query; [Command(13) of C000] 


*This procedure creates request for the CEP to send a progress report to the player. It 
is similar to creating a quick order.* 


For QOP context = 90 invoke Quick Order Displays [C017] 
Do List Control to return the type of reports 

Given a report type do Quick Attribute Displays 

Do Player Order Assignments 

Do Mail the Player Order/Messages 


End Querys 


Graphics Adjusts 
*This procedure makes adjustments to the player's graphics station.* 
For QOP context = 98 invoke Quick Order Displays [C017] 
Do List Control returning the type of adjustment; 
Given an adjustment type invoke Quick Attribute Display; 
Do player Order Assignments 


Do Mail the Player Order/Messages 


End Graphics Adjust} 
*#*#% Find Menu Functions and Procedures *%** 


Find Group} 


*This procedure invokes the operating system finder given the type of "group". * 


End Find Groups 
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Find Directives 


*This procedure invokes the operating system finder given the type of "type of 
directive" .* 


End Find Directives 


Find Utility; 


*This procedure invokes the operating system finder given the type of “type of utility 
directive".* 


End Find Utility; 


Find Message} 
*This procedure invokes the operating system finder given a type "filed messages".* 


End Find Message} 


Find Reports 
*¥This procedure invokes the operating system finder given a type "filed reports".* 


End Find Report; 
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Mouse Click; 


*¥This identifies where the mouse was clicked and invokes the necessary procedure. * 


For location case of : *xSomewhere in the main window. 
Menu bar : Do Handle Menu3 
Content : Do Handle Click *In the main window to handle the attributes. 
Close box : Do Handle Close 


System window : Do System Click *This is a click in a desk accessory. 


End Mouse Click}; 


Keypress} 
*This handles the event of any Keystroke including the use of command Keys.* 


End Keypress} 


Update; 
*This invokes the necessary update procedure depending upon the event.* 


Case of : 
Status window : Do Write The Status3 
Player window : Do Write The Player} 
Main window 
Get the new information to go into the contents3 
Erase the current contents} 
Draw the new contents in it's place} 


End Update3 


Handle Event} 


*This determines what event occurred and handles it.* 


Case of : 


Mouse Click : Do Mouse Click; 
Key down : Do Keypress; 
Autokey : Do Keypress; 
Update event : Do Update; 


Activate event : Do Activate; 


End Handle Event; 


Cursor Adjust; 

*This changes cursors based upon the location of the cursor on the screen. These are 
application specific changes, not those made by the operating system. These may not be 
need for MacMIP but is included here just in case.* 


Do change to cross,» arrow, plus} 


End Cursor Adjust;s— 


Handle Menus3 


*This procedure handles the event of any menu item being hit and invokes the necessary 
action to take place.* 


Case Menu of 


Apple Meru : Case of 
About : Do Abouts 
Desk Accessory : Do Desk Accessory; 
File Menu : Case of 
Create ' : Do Creates 
Open : Operating system feature} 
Save : operating system features 
Save As... : operating system- features 
Close : operating system feature; 
Print : operating system feature; 
Send : Do Send; 
Verify : Do Verifys 
Quit >: operating system feature} 
Group Menu : Case of 
Create : Do Group Create} 
Leave : Do Leave 3} 
Join : Do Joins 
Send : Do Group Send; 
Verify : Do Group Verify; 
Time Increment : Do Increment Group Time} 


Special Menu : Case of 
Transmit Message : Do Transmit Message} 


Receive Message : Do Receive Message} 
Query >: Do Query3 
Graphics : Do Graphics Adjust3 
Find Menu : Case of 
Group : Do Find Group; 
Directive : Do Find Directive; 
Utility : Do Find Utility; 
Message : Do Find Message} 
Report : Do Find Reports 
Edit Menu: Case of 
Undo >: Operating system feature} 
Cut >: operating system feature; 
Copy : operating system feature; 
Paste : operating system features 
Clear : operating system features 
Select All : operating system feature; 
Clear >: operating system features 
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End Handle Menu} 
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Initialization; 


*This procedure initializes the various Macintosh managers, variables, and procedures. 
also initializes the PIF by reading in the appropriate database information. * 


Initializes 
GrafPort, Font, Window, Menu, Text, Dialog, Events Managers. 
Cursors} 
Menus $ 
Windows $ 
Variables; 
Supply Field = “nnnnnnnnn.nn''s 
Supply Min = 0.03 
Supply Max = 999999999. 999993 
Supply Width = 153 


Supply Precision = 53 
Month (1 to 12) = Jan. .Dec} 
Month Length (1 to 12 ) = 31..313 
Load database informations; [1000] 
Write to VAX}3 
"Open [.data ]miscel.dat" 
“Read [.data]miscel.dat" 
Read From VAX} 
Store data into appropriate files; 
Write To VAX} 
"Close [.dataImiscel.dat''s 
“Open [.datalexecutive.dat''s (I001] 
“Read [.datalexecutive.dat"s 
Read From VAX} ° 
Write To VAX; 
“Close [.datalexecutive.dat"' 
"Open [.dataldrctvs<function number>.dat"s; [1003] 
“Read [.dataldrctvs<function number>.dat''s 
Read From Vaxs3 
: Write To VAX; 
“Close [.dataldrctvs<function number>.dat''s 
"Open [.datalalldrctvs.dat'"'s (1003 } 
“Read [.datalalldrctvs.dat'} ' 
Read From VAX} 
Write To VAX; 
“Close (.datalalldrctvs.dat; 
"Open [.data ]quick<function number>.dat''s 
"Read [.data]lquick<function number<.dat"; [1003] 
Read From VAX} 
Write To VAX; 
"Close [.data]quick<function number>.dats 
For MIP mode = “on-line"s 
Write To Vax} 
Call VAX 'SYSSCREMBX' 5 xCreate the mailboxes.[(1I302] 
Read From VAX} xGet the mailbox names. 
Load the PIF; [1003] 
Write To VAX} 
Given function number and type of game = "“start''s 
“Open PF_Unit( file_type)"'$ 
Read From VAX; 


Read game class,» starting day, starting month, starting years 


Latitude/Longitude information; 

Unit names,types, and resource informations 
Target names, types, numbers} 

Supply side/category names, units, multipliers; 
Aircraft informations 

Air weapon informations 
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Sensor package information} 

Emitter suite informations 
Write To VAX: 

Close PF_unit( file_type)}3 


End Initialization} 
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Cleanup} 


*This procedure simply erases the screen when the game is finished, logs off the VAX, and 
shuts down the Macintosh.* 


End Cleanups 
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BEGIN MacMIP}3 


Call Initialization; 
Repeat until finished; 
System Task; *For desk accessories. 
Cursor Adjusts 
If GetNextEvent(everyEvent, theEvent}; *If there is an event... 
Then Handle Event(theEvent); *...then do it. 
Call Cleanups xWhen finished. 


‘END MacMIP. 
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